Introduction To Oracle Net Services

Introduction to Oracle Net Services
Page 1 of 212
1. Introduction to Oracle Net Services

1.1 About Oracle Net Services
Oracle Net Services provides enterprise wide connectivity solutions in distributed, heterogeneous computing environments. Oracle Net Services ease the complexities of network configuration and management, maximize performance, and improve network diagnostic capabilities.
1.2 Connectivity
Oracle Net, a component of Oracle Net Services, enables a network session from a client application to an Oracle Database server. Once a network session is established, Oracle Net acts as the data courier for both the client application and the database server. It is responsible for establishing and maintaining the connection between the client application and database server, as well as exchanging messages between them. Oracle Net is able to perform these jobs because it is located on each computer in the network.
1.2.1 Client/Server Application Connections

Oracle Net enables connections from traditional client/server applications to Oracle Database servers. Figure shows how Oracle Net enables a network connection between a client and a database server. Oracle Net is a software component that resides on both the client and the database server. Oracle Net is layered on top of a network Oracle protocol supportrules that determine how applications access the network and how data is subdivided into packets for transmission across the network. In this illustration, Oracle Net communicates with the TCP/IP protocol to enable computer-level connectivity and data transfer between the client and the database server. Figure - Client/Server Application Connection
Specifically, Oracle Net is comprised of the Oracle Net foundation layer, which establishes and maintains connections, and Oracle protocol support, which maps the foundation layer's technology to industry-standard protocols.
1.2.2. Web Client Application Connections

Internet connections from client Web browsers to an Oracle Database server are similar to client/server applications, except that the connection request goes over an application Web server. Figure shows the basic architecture for Web client connections, including a client Web browser, an application Web server, and an Oracle Database server. The browser on the client communicates with the HTTP protocol to a Web server to make a connection request. The Web server sends the request to an application where it is processed. The application then uses Oracle Net to communicate with an Oracle Database server that also is configured with Oracle Net.
www.wilshiresoft.com info@wilshiresoft.com Wilshire Software Technologies Ph: 2761-2214 / 5577-2214 Rev. Dt: 10-Oct-08 Version: 6
Page 2 of 212
Figure - Web Client Connections through Application Web Server
HTTP provides the language that enables Web browsers and application Web servers to communicate. Application Web Server An application Web server manages data for a Web site, controls access to that data, and responds to requests from Web browsers. The application on the Web server communicates with the database and performs the job requested by the Web server. Web Client Connections through Java Application Web Server An application Web server can host Java applications and servlets. Web browsers make a connection request by communicating through HTTP to an application Web server. The application Web server sends the request to an application or a servlet, which in turn uses a JDBC OCI or a JDBC Thin driver to process the request. The driver then uses Oracle Net to communicate with an Oracle Database server that also is configured with Oracle Net.Oracle Net Services offer a number of manageability features that enable you to easily configure and manage networking components. These features are described in the following topics: Location Transparency Centralized Configuration and Management Quick Installation and Configuration Location Transparency A company can have several databases, each representing a specific type of service for various client applications. For example, a company may have three databases, which it uses for sales, human resources, and marketing applications. Each database is represented by one or more services. A service is identified by a service name, for example, sales.us.acme.com. A client uses this service name to identify the database it needs to access. The information about the database service and its location in the network is transparent to the client because the information needed for a connection is stored in a repository. For example, a company has three databases that clients can access. Each database has a distinct service name: sales.us.acme.com, hr.us.acme.com, and mktg.us.acme.com. 1. The client uses the repository to find the information it needs for sales.us.acme.com. 2. Once the client has the information it needs, it connects to the database. The repository is represented by one or more naming methods. Oracle Net Services offer several types of naming methods that support localized configuration on each client or centralized configuration that can be accessed by all clients in the network. Easy-to-use graphical user interfaces enable you to manage data stored in the naming methods. Centralized Configuration and Management To manage large networking environments, administrators have to be able to easily access a centralized repository to specify and modify the network configuration. For this reason, the Oracle Net Services configuration can be stored in a LDAP-compliant directory server. Support of LDAP-compliant directory servers provides a centralized vehicle for managing and configuring a distributed Oracle network. The directory can act as a central repository for
Page 3 of 212
all information on database network components, user and corporate policies, and user authentication and security, thus replacing client-side and server-side localized configuration files. All computers on the heterogeneous network can refer to the directory for information. Quick Installation and Configuration Oracle Net Services install quickly and easily. Networking elements for the Oracle Database server and clients are preconfigured for most environments. Information about an Oracle Database service is populated in one or more naming methods. As a result, clients and servers are ready to immediately connect when installed, giving users the benefits of distributed computing.
1.3 Prerequisites to Establishing Connectivity

The tasks in this quick start guide show a TCP/IP connection between a client computer and a database server. The following about the database server and client computers is assumed: Database Server Computer It is running on the same network as the client. An Oracle database is installed. TCP/IP protocol support is installed. A listener is configured. Client Computer It is running on the same network as the database server. Oracle Client is installed. TCP/IP protocol support is installed. Task 1: Confirm Network Availability Before using Oracle Net to connect a client computer to a database server, confirm that the client computer can successfully communicate with the database server computer. Evaluating network connectivity can eliminate network-based errors. To confirm network connectivity: 1. Confirm that the database server computer can communicate with itself with a loopback test. A loopback test is a connection from the database server back to itself. Many network protocols provide a means of testing network connections. The utility PING can be used for TCP/IP network. In a TCP/IP network, each computer has a unique IP address. A name resolution service, such as Domain Name System (DNS), can be used to map the IP address of a computer with its host name. If a name resolution service is not used, then the mapping is typically stored in a centrally maintained file called hosts. This file is located in the /etc directory on UNIX and the \winnt directory on Windows. For example, an entry for a database server computer named sales-server may look like the following: #IP address of server host name alias 144.25.186.203 sales-server sales.us.acme.com To use PING, enter the following at the command line: ping database_server_host The database_server_host is the host name of the database server computer. For example: ping sales-server If the loopback was unsuccessful, try using the IP address of the database server. For example: ping 144.25.186.203 2. Verify the client computer can successfully communicate with the database server computer. This varies according to the network protocol. For TCP/IP, you can use PING, FTP or TELNET utilities. If the client computer cannot reach the server, verify that the network cabling and network interface cards are correctly connected. Contact your network administrator to correct these problems. Task 2: Start Oracle Net Listener and the Oracle Database Server Oracle Net Listener and the Oracle Database server must be running in order for the database server to receive connections. 1. Start the listener with the Listener Control utility. From the command line, enter: lsnrctl
Page 4 of 212
LSNRCTL> START [listener_name] Where listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default, named LISTENER.A status message indicating that the listener has started successfully displays. 2. Start the database: a. Start SQL*Plus without connecting to the database: sqlplus /nolog b. Connect to the database as SYSDBA: SQL> CONNECT username as sysdba For example, SYSTEM is a SYSDBA user. You will be prompted to enter a password. Note: For simplicity in demonstrating this feature, this example does not perform the password management techniques that a deployed system normally uses. In a production environment, follow the Oracle Database password management guidelines, and disable any sample accounts. c. Enter the STARTUP command, specifying the database name and full path of the parameter file: SQL> STARTUP database_name pfile=file If you do not specify the PFILE option, the Oracle database uses the standard initialization parameter file located in the $ORACLE_HOME/dbs directory on UNIX platforms, and %ORACLE_HOME%\database directory on Windows. If you do not specify a database name, then the database uses the value of the DB_NAME parameter specified in the initialization parameter file. 3. Confirm that database service registration with the listener has completed. From the Listener Control utility, enter: LSNRCTL> SERVICES [listener_name] The SERVICES command lists the services supported by the database, along with at lease one available service handler. Task 3: Configure the Client for Connection to a Database Once network connectivity has been verified, you can use easy connect naming to connect to the database. NOTE: Oracle Database 11g does not support the use of Oracle Names. Neither Oracle Database 11g clients nor Oracle Databases can use Oracle Names, including by LDAP proxy, to resolve naming. Oracle8i and Oracle9i clients can still use Oracle Names to resolve naming for an Oracle Database 11g database; however, customers are strongly recommended to migrate to LDAP to take advantage of the new features of Oracle Database 11g. The easy connect naming method can eliminate the need for service name lookup in the tnsnames.ora files for TCP/IP environments. This naming method provides out-of-the-box TCP/IP connectivity to databases. It extends the functionality of the host naming method by enabling clients to connect to a database server with an optional port and service name in addition to the host name of the database. CONNECT username/password@host[:port][/service_name][:server][/instance_name] Note: In Oracle Call Interface documentation, server is referred to as connect_type. If you have performed Oracle Database server install in Typical mode, the default service name used by the oracle instance is ORCL, and the following easy connect syntax can be used to connect to that instance: CONNECT username@host/ORCL Enter password: password
1.4 Alternate Connection using Oracle Net Configuration Assistant

If you do not wish to use the easy connect naming method, you can use Oracle Net Configuration Assistant to create a net service name, a simple name for the database service. The net service name resolves to the connect descriptor, that is, the network address of the database and the name of the database service. The client will use the net service name to connect to the database. The following example shows the net service name sales mapped to a connect descriptor for a database called sales.us.acme.com. A client can use sales mapped to connect to sales.us.acme.com. sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))
Page 5 of 212
(CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com))) A successful test results in the following message: Connecting...Test successful. If the test fails, it can be because the: Default username (scott) and password (tiger) are not valid Protocol address information does not match the listener information The listener is not running Destination database service is down
Task 4: Connect to the Database from the client computer, connect to the database server as follows. 1. Start SQL*Plus: sqlplus 2. Connect to the database as follows: CONNECT username@net_service_name Enter password: password Where username and password are the database user and password, and net_service_name is the net service name.
1.5 Connectivity Concepts

1.5.1 Database Service and Database Instance Identification
Database Services An Oracle database is represented to clients as a service, which means that the database performs work on behalf of clients. A database can have one or more services associated with it. Figure shows two databases, each with its own database service for intranet clients. One service, sales.us.acme.com, enables salespersons to access the sales database. Another service, finance.us.acme.com, enables financial analysts to access the finance database. Figure - One Service for Each Database
The sales and finance databases are each identified by a service name, sales.us.acme.com and finance.us.acme.com. The service name is specified by the SERVICE_NAMES initialization parameter in the server parameter file. The service name defaults to the global database name, a name comprising the database name (DB_NAME initialization parameter) and domain name (DB_DOMAIN initialization parameter). In the case of sales.us.acme.com, sales is the database name and us.acme.com is the domain name. Note: You can change the value of SERVICE_NAMES parameter ynamically with the SQL statement ALTER SYSTEM when the database is running. Database Instances A database has at least one instance. An instance is comprised of a memory area called the System Global Area (SGA) and Oracle background processes. The memory and processes of an instance efficiently manage the associated database's data and serve the database users. Like services, instances are identified by an instance
Page 6 of 212
name, sales and finance in this example. The instance name is specified by the INSTANCE_NAME initialization parameter. The instance name defaults to the Oracle System Identifier (SID) of the database instance. Some hardware architectures allow multiple computers to share access to data, software, or peripheral devices. Oracle Real Application Clusters can take advantage of such architecture by running multiple instances on different computers that share a single physical database. Figure - One service for each database
Service Accessibility To connect to a database service, clients use a connect descriptor that provides the location of the database and the name of the database service. The following example shows a connect descriptor that enables clients to connect to a database service called sales.us.acme.com. (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com))) Protocol Address The address portion of the connect descriptor is the protocol address of the listener. To connect to a database service, clients first contact a listener process that typically resides on the database server. The listener receives incoming client connection requests and hands these requests to the database server. After the connection is established, the client and database server communicate directly. Much like a business address, the listener is configured to accept requests from clients at a protocol address. This address defines the protocol the listener is listening on and any other protocol specific information. For example, the listener could be configured to listen at the following protocol address: (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521))) The preceding example shows a TCP/IP protocol address that specifies the host of the listener and a port number. Clients configured with this same protocol address can send connection requests to this listener. Connect Data The connect descriptor also specifies the database service name with which clients seek to establish a connection. The listener knows which services for which it can handle connection requests, because a n Oracle database dynamically registers this information with the listener. This process of registration is called service registration. Registration also provides the listener with information about the database instances and the service handlers available for each instance. Service handlers act as connection points to an Oracle database server. A service handler can be a dispatcher or a dedicated server. Instance Name If connecting to a specific instance of the database is required, clients can also specify the INSTANCE_NAME of a particular instance in the connect descriptor. This feature can be useful if you have an Oracle Real Application Clusters configuration. For example, the following connect descriptor specifies an instance name of sales1 that is associated with sales.us.acme.com. (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA=
Page 7 of 212
(SERVICE_NAME=sales.us.acme.com) (INSTANCE_NAME=sales1))) Service Handlers Alternatively, clients that always want to use a particular service handler type can use a connect descriptor that specifies the service handler type. In the following example, a connect descriptor is configured to use a dispatcher for a shared server configuration, as indicated by (SERVER=shared). (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (SERVER=shared))) If you want the client to use a dedicated server, you can specify (SERVER=dedicated) in place of (SERVER=shared). If the SERVER parameter is not set, shared server configuration is assumed. However, the client will use a dedicated server if no dispatchers are available. If database resident connection pooling is enabled on the server, then you can specify (SERVER=pooled) to get a connection from the pool. If database resident connection pooling is not enabled on the server, then the client request is rejected. When the listener receives the client request; it selects one of the service handlers that were previously registered. Depending on the type of handler selected, the communication protocol used, and the operating system of the database server, the listener performs one of the following actions: Hands the connect request directly off to a dispatcher. Sends a redirect message back to the client with the location of the dispatcher or dedicated server process. The client then connects directly to the dispatcher or dedicated server process. Spawns a dedicated server process and passes the client connection to the dedicated server process.
After the listener has completed the connection operation for the client, the client communicates with the Oracle database without the listener's involvement. The listener resumes listening for incoming network sessions.
1.6 Enhanced Service Accessibility with Multiple Listeners

For some configurations, such as Oracle Real Application Clusters, multiple listeners on multiple nodes can be configured to handle client connection requests for the same database service. In the following example, sales.us.acme.com can connect to sales.us.acme.com using listeners on either sales1-server or sales2-server. (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sales1-server)(PORT=1521)) (ADDRESS=(PROTOCOL=tcp)(HOST=sales2-server)(PORT=1521))) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com))) A multiple-listener configuration also enables you to leverage the following failover and load balancing features, either singly or in combination with each other: Connect-Time Failover The connect-time failover enables clients to connect to another listener if the initial connection to the first listener fails. The number of listener protocol addresses determines how many listeners are tried. Without connect-time failover, Oracle Net attempts a connection with only one listener. Transparent Application Failover The Transparent Application Failover (TAF) feature is a runtime failover for High Availability environments, such as Oracle Real Application Clusters. TAF fails over and reestablishes application-to-service connections. It enables client applications to automatically reconnect to the database if the connection fails and, optionally, resume a SELECT statement that was in progress. The reconnection happens automatically from within the Oracle Call Interface (OCI) library. Client Load Balancing
Page 8 of 212
The client load balancing feature enables clients to randomize connection requests among the listeners. Oracle Net progresses through the list of protocol addresses in a random sequence, balancing the load on the various listeners. Without client load balancing, Oracle Net progresses through the list of protocol addresses sequentially until one succeeds. Connection Load Balancing The connection load balancing feature improves connection performance by balancing the number of active connections among multiple dispatchers. In a single-instance environment, the listener selects the least loaded dispatcher to handle the incoming client requests. In an Oracle Real Application Clusters environment, connection load balancing also has the capability to balance the number of active connections among multiple instances. Due to dynamic service registration, a listener is always aware of all instances and dispatchers regardless of their location. Depending on the load information, a listener decides which instance and, if shared server is configured, to which dispatcher to send the incoming client request. In a shared server configuration, a listener selects a dispatcher in the following order: 1. Least-loaded node 2. Least-loaded instance 3. Least-loaded dispatcher for that instance In a dedicated server configuration, a listener selects an instance in the following order: 1. Least loaded node 2. Least loaded instance If a database service has multiple instances on multiple nodes, the listener chooses the least loaded instance on the least loaded node. If shared server is configured, then the least loaded dispatcher of the selected instance is chosen. Oracle Net Configuration Files:
www.wilshiresoft.com info@wilshiresoft.com
Wilshire Software Technologies Ph: 2761-2214 / 5577-2214
Rev. Dt: 10-Oct-08 Version: 6
Page 9 of 212
1.7 Listener Architecture

The database server receives an initial connection from a client application through the listener. The listener is an application positioned on top of the Oracle Net foundation layer. Figure illustrates the various layers on the client and database server during an initial connection. Figure - Layers Used in an Initial Connection
The listener brokers client requests, handing off the requests to the Oracle database server. Every time a client requests a network session with a database server, a listener receives the initial request. Each listener is configured with one or more protocol addresses that specify its listening endpoints. Clients configured with a protocol address can send connection requests to the listener. Once a client request has reached the listener, the listener selects an appropriate service handler to service the client's request and forwards the client's request to it. The listener determines if a database service and its service handlers are available through service registration. During service registration, the PMON processan instance background processprovides the listener with information about the following: Names of the database services provided by the database Name of the instance associated with the services and its current and maximum load Service handlers (dispatchers and dedicated servers) available for the instance, including their type, protocol addresses, and current and maximum load. This information enables the listener to direct a client's request appropriately. Figure shows instances registering information with listeners. Note that it does not represent all the information that can be registered. Figure - Service Registration
Optionally, listening endpointsport numberscan be dynamically registered with the listener. For example, with Oracle XML DB, HTTP, FTP, and WebDAV listening endpoints are registered with the listener. If the listener is not running when an instance starts, PMON is not able to register the service information. PMON attempts to connect to the listener periodically, however, it may take up to 60 seconds before PMON registers with the listener after it has been started. To initiate service registration immediately after the listener is started; use the SQL statement ALTER SYSTEM REGISTER. This is especially useful in high-availability configurations. If a listener receives an incoming request before the respective instance has been registered, the listener rejects the request.
Page 10 of 212
If an instance is in restricted mode, then PMON instructs the listener to block all connections to the instance. Clients attempting to connect receive one of the following errors: ORA-12526: TNS:listener: all appropriate instances are in restricted mode ORA-12527: TNS:listener: all appropriate instances are in restricted mode or blocking new connections ORA-12528: TNS:listener: all appropriate instances are blocking new connections
1. The database registers information about the services, instances, and service handlers with the listener. 2. The client makes an initial connection with the listener. 3. The listener parses the client request and forwards it to the service handler for the database service requested. Listener Architecture:
Configuring Naming Methods
Page 11 of 212
2. Configuring Naming Methods

2.1 Naming Method Configuration Overview
To connect to a service, clients use a connect identifier in the connect string to connect to a service. The connect identifier can be a connect descriptor or a simple name that maps to a connect descriptor. The connect descriptor contains: Network route to the service, including the location of the listener through a protocol address Oracle8i or later release database service name or Oracle8 data base Oracle System Identifier (SID) A simple name is resolved to a connect descriptor by a naming method. A naming method configuration consists of the following steps: 1. Select a naming method. 2. Map connects descriptors to simple names. 3. Configure clients to use the naming method.
2.2 About Connect Descriptors

A connect descriptor is comprised of one or more protocol addresses of the listener and the connect information for the destination service. The following example shows a connect descriptor mapped to simple name called sales: sales= (DESCRIPTION= (ADDRESS= (PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com))) The ADDRESS section contains the listener protocol address, and the CONNECT_DATA section contains the destination service information. In this example, the destination service is a database service named sales.us.acme.com. When creating a connect descriptor to an Oracle9i or Oracle8i database service, you must identify the service with the SERVICE_NAME parameter. Optionally, you can identify an instance with the INSTANCE_NAME parameter, as shown in the following: sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com) (INSTANCE_NAME=sales))) The values for these parameters come from the SERVICE_NAMES and INSTANCE_NAME parameters in the initialization parameter file. Note that SERVICE_NAMES uses a final S. The SERVICE_NAMES parameter in the initialization parameter file is typically the global database name, a name which includes the database name and domain name entered during installation or database creation. For example, sales.us.acme.com has a database name of sales and a domain of us.acme.com. The INSTANCE_NAME parameter in the initialization parameter file defaults to the SID entered during installation or database creation. When creating a connect a descriptor for an Oracle Database, you identify the service with the SID parameter. The following example shows a connect descriptor for an Oracle Database with a SID of sales: sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SID=sales)))
Page 12 of 212
2.3 Naming Methods

2.3.1 Using the Easy Connect Naming Method
The easy connect naming method eliminates the need for service name lookup in the tnsnames.ora files for TCP/IP environments; in fact, no naming or directory system is required if you use this method. This naming method provides out-of-the-box TCP/IP connectivity to databases. It extends the functionality of the host naming method by enabling clients to connect to a database server with an optional port and service name in addition to the host name of the database: CONNECT username@[//]host[:port][/service_name][:server][/instance_name] Enter password: password If you installed Oracle Database in Typical mode, the default service name used by the oracle instance is ORCL, and the following easy connect syntax can be used to connect to that instance: CONNECT username@host/ORCL Enter password: password Table lists the easy connect syntax elements and descriptions for each. Table - Connect Identifier for Easy Connection Naming Method
The connect identifier converts into the following connect descriptor: (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=host)(PORT=port))
Page 13 of 212
(CONNECT_DATA= (SERVICE_NAME=service_name) (SERVER=server) (INSTANCE_NAME=instance_name))) For example, the following connect strings connect the client to database service sales.us.acme.com with a listening endpoint of 1521 on databa se server sales-server. CONNECT scott@sales-server:1521/sales.us.acme.com CONNECT scott@//sales-server/sales.us.acme.com CONNECT scott@//sales-server.us.acme.com/sales.us.acme.com After each of the preceding connect strings, you must enter a password to connect to the database service. These connect strings convert into the following connect descriptor: (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com))) For URL or JDBC connections, prefix the connect identifier with a double-slash (//). For example: scott@[//]nineva] Enter password: password For SQL connections, preceding the connect identifier with a double-slash (//) is optional. For example: SQL> CONNECT scott@nineva Enter password: password or SQL> CONNECT scott@//nineva Enter password: password Easy Connect Naming Method Examples This section includes various examples of easy connect naming syntax and how each string converts into a connect descriptor.Host only, where the host name is nineva: nineva This connect string converts into the following connect descriptor: (DESCRIPTION= (CONNECT_DATA= (SERVICE_NAME=nineva.us.acme.com)) (ADDRESS= (PROTOCOL=TCP) (HOST=130.35.45.131) (PORT=1521))) Host and port, where the host name is nineva and the port number is 3456: nineva:3456 This connect string converts into the following connect descriptor: (DESCRIPTION= (CONNECT_DATA= (SERVICE_NAME=nineva.us.oracle.com)) (ADDRESS= (PROTOCOL=TCP) (HOST=130.35.45.131) (PORT=3456))) Host and service name, where the host name is nineva and the service name is wanda:
Page 14 of 212
nineva/wanda This connect string converts into the following connect descriptor: (DESCRIPTION= (CONNECT_DATA= (SERVICE_NAME=wanda)) (ADDRESS= (PROTOCOL=TCP) (HOST=130.35.45.131) (PORT=1521))) Host, service name and server, and instance name where the host name is nineva, the service name is wanda, the server is dedicated, and the instance name is inst1: nineva/wanda:dedicated/inst1 This connect string converts into the following connect descriptor: (DESCRIPTION= (CONNECT_DATA= (SERVICE_NAME=wanda) (INSTANCE_NAME=inst1) (SERVER=dedicated)) (ADDRESS= (PROTOCOL=TCP) (HOST=130.35.45.131) (PORT=1521))) Host and instance name, where the host name is nineva and the instance name is inst1: nineva//inst1 This connect string converts into the following connect descriptor: (DESCRIPTION= (CONNECT_DATA= (SERVICE_NAME=nineva.us.oracle.com) (INSTANCE_NAME=inst1)) (ADDRESS= (PROTOCOL=TCP) (HOST=130.35.45.131) (PORT=1521)))
2.3.2 Using Easy Connect Naming on the Client

Clients can connect to Oracle Database using easy connect naming if the following conditions are met: Oracle Net Services software installed on the client. Oracle TCP/IP protocol support on both the client and database server No features requiring a more advanced connect descriptor are required
For large or complex environments where advanced features, such as connection pooling, external procedure calls, or Heterogeneous Services, which require additional connect information, are desired, easy connect naming is not suitable. In these cases, another naming method is recommended. Easy connect naming is automatically configured at installation. Prior to using it, you may want to ensure that EZCONNECT is specified by the NAMES.DIRECTORY_PATH parameter in the sqlnet.ora file. This parameter specifies the order of naming methods Oracle Net can use to resolve connect identifiers to connect descriptors.
2.4 Configuring the Local Naming Method

The local naming method adds net service names to the tnsnames.ora file. Each net service name maps to a connect descriptor. The following example shows a net service name mapped to a connect descriptor:
Page 15 of 212
sales= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (CONNECT_DATA= (SERVICE_NAME=sales.us.acme.com))) In this example, the net service name sales is mapped to the connect descriptor contained in DESCRIPTION. DESCRIPTION contains the protocol address and identifies the destination database service.
Oracle Net Listener Administration
Page 16 of 212
3. Oracle Net Listener Administration

Oracle Net Listener is a separate process that runs on the database server computer. It receives incoming client connection requests and manages the traffic of these requests to the database server.
3.1 Oracle Net Listener Configuration Overview

Note: Oracle Database 10g and later databases require a version 10 or later listener. Earlier versions of the listener are not supported for use with Oracle Database 10g and later databases. However, you can use a version 10 listener with previous versions of Oracle Database. A listener is configured with one or more listening protocol addresses, information about supported services, and parameters that control its runtime behavior. The listener configuration is stored in a configuration file named listener.ora. Because all of the configuration parameters have default values; it is possible to start and use a listener with no configuration. This default listener has a name of LISTENER, supports no services on startup, and listens on the following TCP/IP protocol address: (ADDRESS=(PROTOCOL=tcp)(HOST=host_name)(PORT=1521)) Supported services, that is, the services to which the listener forwards client requests, can be configured in the listener.ora file or this information can be dynamically registered with the listener. This dynamic registration feature is called service registration. The registration is performed by the PMON processan instance background processof each database instance that has the necessary configuration in the database initialization parameter file. Dynamic service registration does not require any configuration in the listener.ora file. Service registration offers the following benefits: Simplified configuration Service registration reduces the need for the SID_LIST_listener_name parameter setting, which specifies information about the databases served by the listener, in the listener.ora file. Note: The SID_LIST_listener_name parameter is still required if you are using Oracle Enterprise Manager to manage the database. Connect-time failover Because the listener always monitors the state of the instances, service registration facilitates automatic failover of the client connect request to a different instance if one instance is down. In a static configuration model, a listener starts a dedicated server when it receives a client request. If the instance is not up, the server will return an "Oracle not available" error message. Connection load balancing Service registration enables the listener to forward client connect requests to the least-loaded instance and dispatcher or dedicated server. Service registration balances the load across the service handlers and nodes.
3.1.1 Oracle Net Listener Configuration during Installation

Oracle Universal Installer launches Oracle Net Configuration Assistant during software installation. Oracle Net Configuration Assistant configures the listening protocol address and service information for Oracle Database. During an Enterprise Edition or Standard Edition installation on the database server, Oracle Net Configuration Assistant automatically configures a listener with a name of LISTENER that has a TCP/IP listening protocol address for Oracle Database. During a Custom installation, Oracle Net Configuration Assistant prompts you to configure a listener name and a protocol address of your choice. Additionally, a listening IPC protocol address for external procedure calls is automatically configured, regardless of the installation type. Oracle Net Configuration Assistant also automatically configures service information for the external procedures in the listener.ora file.
Page 17 of 212
Example - shows a sample listener.ora file. The LISTENER entry defines the listening protocol address for a listener named LISTENER, and the SID_LIST_LISTENER entry provides information about the services statically supported by the listener LISTENER. Example - Example listener.ora File LISTENER= (DESCRIPTION= (ADDRESS_LIST= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1521)) (ADDRESS=(PROTOCOL=ipc)(KEY=extproc)))) SID_LIST_LISTENER= (SID_LIST= (SID_DESC= (SID_NAME=plsextproc) (ORACLE_HOME=/oracle10g) (PROGRAM=extproc))) If you are using the IPC protocol, you can improve performance by specifying the maximum number of concurrent IPC connection requests to match your expected connection requests. In listener.ora for example, you can specify the value as in the following exa mple: listener_name=(description=(address=(protocol=ipc)(key=listener0)(queuesize=50)))
3.1.2 Customizing Oracle Net Listener Configuration

If the default or installed configuration is not adequate for a particular environment, you can use Oracle Net Manager to customize the listener.ora configuration. While processing a client connection request, the listener tries to match the value of this parameter with the value of the SERVICE_NAME parameter in the client connect descriptor. If the client connect descriptor uses the SID parameter, then the listener does not attempt to map the values. This parameter is primarily intended for configurations with Oracle8 release 8.0 databases (where dynamic service registration is not supported for dedicated servers). This parameter may also be required for use with Oracle8i and higher database services by some configurations. The value for this parameter is typically obtained from the combination of the DB_NAME and DB_DOMAIN parameters (DB_NAME.DB_DOMAIN) in the initialization parameter file, but the value can also contain any valid name used by clients to identify the service. Oracle Home Directory ORACLE_HOME On UNIX, this setting is optional. Use it to specify the Oracle home location of the instance. Without this setting, the listener assumes its Oracle home for the instance. On Windows, this setting is ignored. The Oracle home specified by the ORACLE_HOME parameter in HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE\HOMEID of the Windows registry is used.
3.1.3 Configuring Passwords for Oracle Net Listener

Oracle Net Listener Control (lsnrctl) is the command-line utility for managing Oracle Net Listener configuration, including passwords. A password can be configured for the listener to provide security for listener administrative operations, such as starting or stopping the listener, viewing a list of supported services, or saving changes to the Listener Control configuration. However, as mentioned earlier, local administration of the listener is secure by default through the local operating system. Therefore configuring a password is neither required nor recommended for secure local administration.
3.1.4 Changing the Oracle Net Listener Password

To change the listener password, use the Listener Control utility's CHANGE_PASSWORD command or Oracle Enterprise Manager to set or modify an encrypted password in the PASSWORDS_listener_name parameter in the listener.ora file. If the PASSWORDS_listener_name parameter is set to an unencrypted password, you must
Page 18 of 212
manually remove it from the listener.ora file prior to modifying it. If the unencrypted password is not removed, you will be unable to successfully set an encrypted password. To set a new encrypted password with the CHANGE_PASSWORD command, issue the following commands from the Listener Control utility: LSNRCTL> CHANGE_PASSWORD Old password: old_password New password: new_secure_password Reenter new password: new_secure_password Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tpc)(HOST=sales-server)(PORT=1521))) Password changed for LISTENER The command completed successfully LSNRCTL> SAVE_CONFIG Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521))) Saved LISTENER configuration parameters. Listener Parameter File Old Parameter File /oracle/network/admin/listener.ora
/oracle/network/admin/listener.bak
The command completed successfully Bold denotes user input. The password is not displayed when entered. To modify an encrypted password with the CHANGE_PASSWORD command: LSNRCTL> SET PASSWORD Password: password The command completed successfully LSNRCTL> CHANGE_PASSWORD Old password: old_password New password: new_secure_password Reenter new password: new_secure_password Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=tpc)(HOST=sales-server)(PORT=1521))) Password changed for LISTENER The command completed successfully LSNRCTL> SAVE_CONFIG Connecting to (DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=sales-server)(PORT=1521))) Saved LISTENER configuration parameters. Listener Parameter File Old Parameter File /oracle/network/admin/listener.ora
/oracle/network/admin/listener.bak
3.2 Registering Information with a Non-default Listener

If you want PMON to register with a local listener that does not use TCP/IP, port 1521, configure the LOCAL_LISTENER parameter in the initialization parameter file to locate the local listener. For a shared server environment, you can alternatively use the LISTENER attribute of the DISPATCHERS parameter in the initialization parameter file to register the dispatchers with a non-default local listener. Because both the LOCAL_LISTENER parameter and the LISTENER attribute enable PMON to register dispatcher information with the listener, it is not necessary to specify both the parameter and the attribute if the listener values are the same. Set the LOCAL_LISTENER parameter as follows: LOCAL_LISTENER=listener_alias Set the LISTENER attribute as follows:
Page 19 of 212
DISPATCHERS="(PROTOCOL=tcp)(LISTENER=listener_alias)" listener_alias is then resolved to the listener protocol addresses through a naming method, such as a tnsnames.ora file on the database server.For example, if the listener is configured to listen on port 1421 rather than port 1521, you can set the LOCAL_LISTENER parameter in the initialization parameter file as follows: LOCAL_LISTENER=listener1 Using the same listener example, you can set the LISTENER attribute as follows: DISPATCHERS="(PROTOCOL=tcp)(LISTENER=listener1)" You can then resolve listener1 in the local tnsnames.ora as follows: listener1= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1421))) Notes: To dynamically update the LOCAL_LISTENER parameter, use the SQL statement ALTER SYSTEM: ALTER SYSTEM SET LOCAL_LISTENER='listener_alias' If you set the parameter to null with the statement that follows, then the default local address of TCP/IP, port 1521 is assumed. ALTER SYSTEM SET LOCAL_LISTENER='' The LISTENER attribute overrides the LOCAL_LISTENER parameter. As a result, the SQL statement ALTER SYSTEM SET LOCAL_LISTENER does not affect the setting of this attribute.
3.3 Configuring a Naming Method

The listener name alias specified for the LOCAL_LISTENER parameter, REMOTE_LISTENER parameter, or LISTENER attribute can be resolved through a tnsnames.ora file. For example, if LOCAL_LISTENER is set to listener1 and listener1 uses TCP/IP on port 1421, the entry in the tnsnames.ora file would be: listener1= (ADDRESS=(PROTOCOL=tcp)(HOST=sales-server)(PORT=1421)) Note: Multiple addresses are supported, but connect-time failover and client load ba lancing features are not supported.
3.4 Listener Administration

Once the listener is configured, the listener can be administered with the Listener Control utility or Oracle Enterprise Manager. Starting and Stopping a Listener To stop or start a listener, use either the Listener Control utility or Oracle Enterprise Manager.
Note: You can configure the listener to start automatically whenever the computer it is running on is restarted. Using the Listener Control Utility to Start or Stop a Listener To stop a listener from the command line, enter: lsnrctl STOP [listener_name] Where listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default listener, named LISTENER. To start the listener from the command line, enter: lsnrctl START [listener_name] where listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default listener, named LISTENER.
Page 20 of 212
3.4.1 Determining the Current Status of a Listener

To show the current status of a listener, use either the STATUS command of the Listener Control utility or Oracle Enterprise Manager. The status output provides basic status information about a listener, a summary of listener configuration settings, the listening protocol addresses, and a summary of services registered with the listener.
3.4.2 Using the Listener Control Utility to Determine the Listener Status
The STATUS command provides basic status information about a listener, including a summary of listener configuration settings, the listening protocol addresses, and a summary of services registered with the listener.To show the status the listener from the command line, enter: lsnrctl STATUS [listener_name] Where listener_name is the name of the listener defined in the listener.ora file. It is not necessary to identify the listener if you are using the default listener, named LISTENER.
3.4.3 Monitoring Services of a Listener

The SERVICES command of the Listener Control utility provides detailed information about the services and instances registered with a listener and the service handlers allocated to each instance.
Distributed Transactions Concepts
Page 21 of 212
4. Distributed Transactions Concepts

4.1. What Are Distributed Transactions?
A distributed transaction includes one or more statements that, individually or as a group, update data on two or more distinct nodes of a distributed database. For example, assume the database configuration depicted in Figure: Figure: Distributed System
The following distributed transaction executed by scott updates the local sales database, the remote hq database, and the remote maint database: UPDATE scott.dept@hq.us.acme.com SET loc = 'REDWOOD SHORES' WHERE deptno = 10; UPDATE scott.emp SET deptno = 11 WHERE deptno = 10; UPDATE scott.bldg@maint.us.acme.com SET room = 1225 WHERE room = 1163; COMMIT; Note: If all statements of a transaction reference only a single remote node, then the transaction is remote, not distributed. There are two types of permissible operations in distributed transactions: DML and DDL Transactions The following are the DML and DDL operations supported in a distributed transaction: CREATE TABLE AS SELECT DELETE INSERT (default and direct load) LOCK TABLE
Wilshire Software Technologies Ph: 2761-2214 / 5577-2214 Rev. Dt: 10-Oct-08 Version: 6
Page 22 of 212
SELECT SELECT FOR UPDATE
You can execute DML and DDL statements in parallel and INSERT direct load statements serially, but note the following restrictions: All remote operations must be SELECT statements. These statements must not be clauses in another distributed transaction. If the table referenced in the table_expression_clause of an INSERT, UPDATE, or DELETE statement is remote, then execution is serial rather than parallel. You cannot perform remote operations after issuing parallel DML/DDL or direct load INSERT. If the transaction begins using XA or OCI, it executes serially. No loopback operations can be performed on the transaction originating the parallel operation. For example, you cannot reference a remote object that is actually a synonym for a local object. If you perform a distributed operation other than a SELECT in the transaction, no DML is parallelized.
Transaction Control Statements The following are the supported transaction control statements: COMMIT ROLLBACK SAVEPOINT
4.2. Managing a Distributed Database

4.2.1 Database Links
The central concept in distributed database systems is a database link. A database link is a connection between two physical database servers that allows a client to access them as one logical database. What Are Database Links? A database link is a pointer that defines a one-way communication path from an Oracle Database server to another database server. The link pointer is actually defined as an entry in a data dictionary table. To access the link, you must be connected to the local database that contains the data dictionary entry. A database link connection is oneway in the sense that a client connected to local database A can use a link stored in database A to access information in remote database B, but users connected to database B cannot use the same link to access data in database A. If local users on database B want to access data on database A, then they must define a link that is stored in the data dictionary of database B.A database link connection allows local users to access data on a remote database. For this connection to occur, each database in the distributed system must have a unique global database name in the network domain. The global database name uniquely identifies a database server in a distributed system. Figure shows an example of user scott accessing the emp table on the remote database with the global name hq.acme.com:
Page 23 of 212
Figure Database Link
Database links are either private or public. If they are private, then only the user who created the link has access; if they are public, then all database users have access. One principal difference among database links is the way that connections to a remote database occur. Users access a remote database through the following types of links: What Are Shared Database Links? A shared database link is a link between a local server process and the remote database. The link is shared because multiple client processes can use the same link simultaneously. When a local database is connected to a remote database through a database link, either database can run in dedicated or shared server mode. The following table illustrates the possibilities: Local Database Mode Dedicated Dedicated Shared server Shared server Remote Database Mode Dedicated Shared server Dedicated Shared server
A shared database link can exist in any of these four configurations. Shared links differ from standard database links in the following ways: Different users accessing the same schema object through a database link can share a network connection. When a user needs to establish a connection to a remote server from a particular server process, the process can reuse connections already established to the remote server. The reuse of the connection can occur if the connection was established on the same server process with the same database link, possibly in a different session. In a non-shared database link, a connection is not shared across multiple sessions. When you use a shared database link in a shared server configuration, a network connection is established
Page 24 of 212
directly out of the shared server process in the local server. For a non-shared database link on a local shared server, this connection would have been established through the local dispatcher, requiring context switches for the local dispatcher, and requiring data to go through the dispatcher.
4.2.2. Why Use Database Links?

The great advantage of database links is that they allow users to access another user's objects in a remote database so that they are bounded by the privilege set of the object owner. In other words, a local user can access a link to a remote database without having to be a user on the remote database. For example, assume that employees submit expense reports to Accounts Payable (A/P), and further suppose that a user using an A/P application needs to retrieve information about employees from the hq database. The A/P users should be able to connect to the hq database and execute a stored procedure in the remote hq database that retrieves the desired information. The A/P users should not need to be hq database users to do their jobs; they should only be able to access hq information in a controlled way as limited by the procedure.
4.2.3 Global Database Names in Database Links

To understand how a database link works, you must first understand what a global database name is. Each database in a distributed database is uniquely identified by its global database name. The database forms a global database name by prefixing the database network domain, specified by the DB_DOMAIN initialization parameter at database creation, with the individual database name, specified by the DB_NAME initialization parameter. For example, Figure illustrates a representative hierarchical arrangement of databases throughout a network.
The name of a database is formed by starting at the leaf of the tree and following a path to the root. For example, the mfg database is in division3 of the acme_tools branch of the com domain. The global database name for mfg is created by concatenating the nodes in the tree as follows: mfg.division3.acme_tools.com While several databases can share an individual name, each database must have a unique global database name. For example, the network domains us.americas.acme_auto.com and uk.europe.acme_auto.com each contain a sales database. The global database naming system distinguishes the sales database in the americas division from the sales database in the europe division as follows: sales.us.americas.acme_auto.com sales.uk.europe.acme_auto.com Names for Database Links Typically, a database link has the same name as the global database name of the remote database that it references. For example, if the global database name of a database is sales.us.oracle.com, then the database link is also called sales.us.oracle.com. When you set the initialization parameter GLOBAL_NAMES to TRUE, the database ensures that the name of the database link is the same as the global database name of the remote database. For example, if the global database name for hq is hq.acme.com, and GLOBAL_NAMES is TRUE, then the link name must be called hq.acme.com. Note that the database checks the domain part of the global database name as stored in the data dictionary, not the DB_DOMAIN setting in the initialization parameter file.
Page 25 of 212
If you set the initialization parameter GLOBAL_NAMES to FALSE, then you are not required to use global naming. You can then name the database link whatever you want. For example, you can name a database link to hq.acme.com as foo. Note: Oracle recommends that you use global naming because many useful features, including Replication, require global naming. After you have enabled global naming, database links are essentially transparent to users of a distributed database because the name of a database link is the same as the global name of the database to which the link points. For example, the following statement creates a database link in the local database to remote database sales: CREATE PUBLIC DATABASE LINK sales.division3.acme.com USING 'sales1';
4.3. Types of Database Links

Oracle Database lets you create private, public, and global database links. These basic link types differ according to which users are allowed access to the remote database:
Determining the type of database links to employ in a distributed database depends on the specific requirements of the applications using the system. Consider these features when making your choice:
Page 26 of 212
4.4. Creating Database Links

To support application access to the data and schema objects throughout a distributed database system, you must create all necessary database links. This section contains the following topics:
4.4.1. Obtaining Privileges Necessary for Creating Database Links

A database link is a pointer in the local database that lets you access objects on a remote database. To create a private database link, you must have been granted the proper privileges. The following table illustrates which privileges are required on which database for which type of link: To see which privileges you currently have available, query ROLE_SYS_PRIVS. For example, you could create and execute the following privs.sql script (sample output included): SELECT DISTINCT PRIVILEGE AS "Database Link Privileges" FROM ROLE_SYS_PRIVS WHERE PRIVILEGE IN ( 'CREATE SESSION','CREATE DATABASE LINK', 'CREATE PUBLIC DATABASE LINK') / SQL> @privs
Database Link Privileges ---------------------------------------CREATE DATABASE LINK CREATE PUBLIC DATABASE LINK CREATE SESSION
Page 27 of 212
4.4.2 Specifying Link Types

When you create a database link, you must decide who will have access to it. The following sections describe how to create the three basic types of links: Creating Private Database Links To create a private database link, specify the following (where link_name is the global database name or an arbitrary link name): CREATE DATABASE LINK link_name ...; Following are examples of private database links: SQL Statement Result CREATE DATABASE LINK A private link using the global database name to the supply.us.acme.com; remote supply database. The link uses the userid/password of the connected user. So if scott (identified by tiger) uses the link in a query, the link establishes a connection to the remote database as scott/tiger. CREATE DATABASE LINK link_2 A private fixed user link called link_2 to the CONNECT TO jane IDENTIFIED database with service name us_supply. The link BY doe USING 'us_supply'; connects to the remote database with the userid/password of jane/doe regardless of the connected user. CREATE DATABASE LINK link_1 a private link called link_1 to the database with CONNECT TO CURRENT_USER service name us_supply. The link uses the USING 'us_supply'; userid/password of the current user to log onto the remote database. Note: The current user may not be the same as the connected user, and must be a global user on both databases involved in the link Current user links are part of the Oracle Advanced Security option. Creating Public Database Links To create a public database link, use the keyword PUBLIC (where link_name is the global database name or an arbitrary link name): CREATE PUBLIC DATABASE LINK link_name ...; Creating Global Database Links In earlier releases, you defined global database links in the Oracle Names server. The Oracle Names server has been deprecated. Now, you can use a directory server in which databases are identified by net service names. In this document these are what are referred to as global database links.
4.4.3 Specifying Link Users

A database link defines a communication path from one database to another. When an application uses a database link to access a remote database, Oracle Database establishes a database session in the remote database on behalf of the local application request. When you create a private or public database link, you can determine which schema on the remote database the link will establish connections to by creating fixed user, current user, and connected user database links. Creating Fixed User Database Links To create a fixed user database link, you embed the credentials (in this case, a username and password) required to access the remote database in the definition of the link: CREATE DATABASE LINK ... CONNECT TO username IDENTIFIED BY password ...; When an application uses a fixed user database link, the local server always establishes a connection to a fixed remote schema in the remote database. The local server also sends the fixed user's credentials across the network when an application uses the link to access the remote database. Creating Connected User and Current User Database Links Connected user and current user database links do not include credentials in the definition of the link. The credentials used to connect to the remote database can change depending on the user that references the database link and the operation performed by the application.
Page 28 of 212
Note: For many distributed applications, you do not want a user to have privileges in a remote database. One simple way to achieve this result is to create a procedure that contains a fixed user or current user database link within it. In this way, the user accessing the procedure temporarily assumes someone else's privileges. Creating a Connected User Database Link to create a connected user database link, omit the CONNECT TO clause. The following syntax creates a connected user database link, where dblink is the name of the link and net_service_name is an optional connect string: CREATE [SHARED] [PUBLIC] DATABASE LINK dblink ... [USING net_service_name']; For example, to create a connected user database link, use the following syntax: CREATE DATABASE LINK sales.division3.acme.com USING 'sales'; Creating a Current User Database Link to create a current user database link, use the CONNECT TO CURRENT_USER clause in the link creation statement. Current user links are only available through the Oracle Advanced Security option. The following syntax creates a current user database link, where dblink is the name of the link and net_service_name is an optional connect string: CREATE [SHARED] [PUBLIC] DATABASE LINK dblink CONNECT TO CURRENT_USER [USING 'net_service_name']; For example, to create a connected user database link to the sales database, you might use the following syntax: CREATE DATABASE LINK sales CONNECT TO CURRENT_USER USING 'sales'; Note: To use a current user database link, the current user must be a global user on both databases involved in the link.
4.4.4. Using Connection Qualifiers to Specify Service Names within Link Names
In some situations, you may want to have several database links of the same type (for example, public) that point to the same remote database, yet establish connections to the remote database using different communication pathways. Some cases in which this strategy is useful are: A remote database is part of an Oracle Real Application Clusters configuration, so you define several public database links at your local node so that connections can be established to specific instances of the remote database. Some clients connect to the Oracle Database server using TCP/IP while others use DECNET. To facilitate such functionality, the database lets you create a database link with an optional service name in the database link name. When creating a database link, a service name is specified as the trailing portion of the database link name, separated by an @ sign, as in @sales. This string is called a connection qualifier. For example, assume that remote database hq.acme.com is managed in a Oracle Real Application Clusters environment. The hq database has two instances named hq_1 and hq_2. The local database can contain the following public database links to define pathways to the remote instances of the hq database: CREATE PUBLIC DATABASE LINK hq.acme.com@hq_1 USING 'string_to_hq_1'; CREATE PUBLIC DATABASE LINK hq.acme.com@hq_2 USING 'string_to_hq_2'; CREATE PUBLIC DATABASE LINK hq.acme.com USING 'string_to_hq'; Notice in the first two examples that a service name is simply a part of the database link name. The text of the service name does not necessarily indicate how a connection is to be established; this information is specified in the service name of the USING clause. Also notice that in the third example, a service name is not specified as part of the link name. In this case, just as when a service name is specified as part of the link name, the instance is determined by the USING string. To use a service name to specify a particular instance, include the service name at the end of the global object name: SELECT * FROM scott.emp@hq.acme.com@hq_1 Note that in this example, there are two @ symbols.
Page 29 of 212
4.5. Managing Database Links

This section contains the following topics:
4.5.1. Closing Database Links

If you access a database link in a session, then the link remains open until you close the session. A link is open in the sense that a process is active on each of the remote databases accessed through the link. This situation has the following consequences: If 20 users open sessions and access the same public link in a local database, then 20 database link connections are open. If 20 users open sessions and each user accesses a private link, then 20 database link connections are open. After you close a session, the links that were active in the session are automatically closed. You may have occasion to close the link manually. For example, close links when: The network connection established by a link is used infrequently in an application. The user session must be terminated. If one user starts a session and accesses 20 different links, then 20 database link connections are open.
If you want to close a link, issue the following statement, where linkname refers to the name of the link: ALTER SESSION CLOSE DATABASE LINK linkname; Note that this statement only closes the links that are active in your current session.
4.5.2. Dropping Database Links

You can drop a database link just as you can drop a table or view. If the link is private, then it must be in your schema. If the link is public, then you must have the DROP PUBLIC DATABASE LINK system privilege. The statement syntax is as follows, where dblink is the name of the link: DROP [PUBLIC] DATABASE LINK dblink; Procedure for Dropping a Private Database Link 1. Connect to the local database using SQL*Plus. For example, enter: CONNECT scott@local_db 2. Query USER_DB_LINKS to view the links that you own. For example, enter: SELECT DB_LINK FROM USER_DB_LINKS; DB_LINK ----------------------------------SALES.US.ORACLE.COM MKTG.US.ORACLE.COM 2 rows selected. 3. Drop the desired link using the DROP DATABASE LINK statement. For example, enter: DROP DATABASE LINK sales.us.oracle.com; Procedure for Dropping a Public Database Link 1. Connect to the local database as a user with the DROP PUBLIC DATABASE LINK privilege. For example, enter: CONNECT SYSTEM@local_db AS SYSDBA 2. Query DBA_DB_LINKS to view the public links. For example, enter: SELECT DB_LINK FROM USER_DB_LINKS WHERE OWNER = 'PUBLIC'; DB_LINK ----------------------------------www.wilshiresoft.com info@wilshiresoft.com Wilshire Software Technologies Ph: 2761-2214 / 5577-2214 Rev. Dt: 10-Oct-08 Version: 6
Page 30 of 212
DBL1.US.ORACLE.COM SALES.US.ORACLE.COM INST2.US.ORACLE.COM RMAN2.US.ORACLE.COM 4 rows selected. 3. Drop the desired link using the DROP PUBLIC DATABASE LINK statement. For example, enter: DROP PUBLIC DATABASE LINK sales.us.oracle.com;
4.5.3. Limiting the Number of Active Database Link Connections

You can limit the number of connections from a user process to remote databases using the static initialization parameter OPEN_LINKS. This parameter controls the number of remote connections that a single user session can use concurrently in distributed transactions. Note the following considerations for setting this parameter: The value should be greater than or equal to the number of databases referred to in a single SQL statement that references multiple databases. Increase the value if several distributed databases are accessed over time. Thus, if you regularly access three databases, set OPEN_LINKS to 3 or greater. The default value for OPEN_LINKS is 4. If OPEN_LINKS is set to 0, then no distributed transactions are allowed.
4.6. Viewing Information about Database Links

The data dictionary of each database stores the definitions of all the database links in the database. You can use data dictionary tables and views to gain information about the links. Determining Which Links Are in the Database The following views show the database links that have been defined at the local database and stored in the data dictionary:
RMAN Tablespace Point-in-Time Recovery
Page 31 of 212
5. Export and Import

This chapter describes how to use the original Export and Import utilities, invoked with the exp and imp command, respectively. These are called the original Export and Import utilities to differentiate them from the Oracle Data Pump Export and Import utilities available as of Oracle Database 10g. The Data Pump Export and Import utilities are invoked with the expdp and impdp commands, respectively. Note: Original export is desupported for general use as of Oracle Database 11g. The only supported use of Original Export in 11g is backward migration of XMLType data to a database version 10g release 2 (10.2) or earlier. Therefore, Oracle recommends that you use the new Data Pump Export and Import utilities, except in the following situations which require Original Export and Import: You want to import files that were created using the original Export utility (exp). You want to export files that will be imported using the original Import utility (imp). An example of this would be if you wanted to export data from Oracle Database 10g and then import it into an earlier database release.
5.1. Export and Import Utilities

The Export and Import utilities provide a simple way for you to transfer data objects between Oracle databases, even if they reside on platforms with different hardware and software configurations. When you run Export against an Oracle database, objects (such as tables) are extracted, followed by their related objects (such as indexes, comments, and grants), if any. The extracted data is written to an export dump file. The Import utility reads the object definitions and table data from the dump file. An export file is an Oracle binary-format dump file that is typically located on disk or tape. The dump files can be transferred using FTP or physically transported (in the case of tape) to a different site. The files can then be used with the Import utility to transfer data between databases that are on systems not connected through a network. The files can also be used as backups in addition to normal backup procedures. Export dump files can only be read by the Oracle Import utility. The version of the Import utility cannot be earlier than the version of the Export utility used to create the dump file. You can also display the contents of an export file without actually performing an import. To do this, use the Import SHOW parameter. To load data from ASCII fixed-format or delimited files, use the SQL*Loader utility.
5.2. Before Using Export and Import

Before you begin using Export and Import, be sure you take care of the following items (described in detail in the following sections): Run the catexp.sql or catalog.sql script Ensure there is sufficient disk or tape storage to write the export file Verify that you have the required access privileges
5.2.1. Running catexp.sql or catalog.sql

To use Export and Import, you must run the script catexp.sql or catalog.sql (which runs catexp.sql) after the database has been created or migrated to Oracle Database 10g.The catexp.sql or catalog.sql script needs to be run only once on a database. The script performs the following tasks to prepare the database for export and import operations: Creates the necessary export and import views in the data dictionary Creates the EXP_FULL_DATABASE role Assigns all necessary privileges to the EXP_FULL_DATABASE and IMP_FULL_DATABASE roles Assigns EXP_FULL_DATABASE and IMP_FULL_DATABASE to the DBA role Records the version of catexp.sql that has been installed
Page 32 of 212
5.2.2. Ensuring Sufficient Disk Space for Export Operations

Before you run Export, ensure that there is sufficient disk or tape storage space to write the export file. If there is not enough space, Export terminates with a write-failure error. You can use table sizes to estimate the maximum space needed. You can find table sizes in the USER_SEGMENTS view of the Oracle data dictionary. The following query displays disk usage for all tables: SELECT SUM(BYTES) FROM USER_SEGMENTS WHERE SEGMENT_TYPE='TABLE'; The result of the query does not include disk space used for data stored in LOB (large object) or VARRAY columns or in partitioned tables.
5.2.3. Verifying Access Privileges for Export and Import Operations

To use Export and Import, you must have the CREATE SESSION privilege on an Oracle database. This privilege belongs to the CONNECT role established during database creation. To export tables owned by another user, you must have the EXP_FULL_DATABASE role enabled. This role is granted to all database administrators (DBAs). If you do not have the system privileges contained in the EXP_FULL_DATABASE role, you cannot export objects contained in another user's schema. For example, you cannot export a table in another user's schema, even if you created a synonym for it. A number of system schemas cannot be exported because they are not user schemas; they contain Oracle-managed data and metadata. Examples of schemas that are not exported include SYS, ORDSYS, and MDSYS. You can perform an import operation even if you did not create the export file. However, keep in mind that if the export file was created by a user with the EXP_FULL_DATABASE role, then you must have the IMP_FULL_DATABASE role to import it. Both of these roles are typically assigned to database administrators (DBAs).You can invoke Export and Import, and specify parameters by using any of the following methods: Command-line entries Parameter files Interactive mode
Before you use one of these methods, be sure to read the descriptions of the available parameters. Note: The import job attributes, LOG_USER and PRIV_USER, are always set to the importing user regardless of what their values were during the export operation. For example, if you perform an export as user scott, but then import as user system, any jobs in the dump file set will be created with LOG_USER and PRIV_USER = SYSTEM. To work around this restriction, you must export and import the job as the job owner.
5.3. Invoking Export and Import as SYSDBA

SYSDBA is used internally and has specialized functions; its behavior is not the same as for generalized users. Therefore, you should not typically need to invoke Export or Import as SYSDBA, except in the following situations: At the request of Oracle technical support When importing a transportable tablespace set
Command-Line Entries You can specify all valid parameters and their values from the command line using the following syntax (you will then be prompted for a username and password): exp PARAMETER=value or exp PARAMETER=(value1,value2,...,valuen) The number of parameters cannot exceed the maximum length of a command line on the system. Note that the examples could use imp to invoke Import rather than exp to invoke Export.
Page 33 of 212
Parameter Files The information in this section applies to both Export and Import, but the examples show use of the Export command, exp.You can specify all valid parameters and their values in a parameter file. Storing the parameters in a file allows them to be easily modified or reused, and is the recommended method for invoking Export. If you use different parameters for different databases, you can have multiple parameter files.Create the parameter file using any flat file text editor. The command-line option PARFILE=filename tells Export to read the parameters from the specified file rather than from the command line. For example:The syntax for parameter file specifica tions is one of the following: PARAMETER=value PARAMETER=(value) PARAMETER=(value1, value2, ...) The following example shows a partial parameter file listing: FULL=y FILE=dba.dmp GRANTS=y INDEXES=y CONSISTENT=y Note: The maximum size of the parameter file may be limited by the operating system. The name of the parameter file is subject to the file-naming conventions of the operating system. You can add comments to the parameter file by preceding them with the pound (#) sign. Export ignores all characters to the right of the pound (#) sign. You can specify a parameter file at the same time that you are entering parameters on the command line. In fact, you can specify the same parameter in both places. The position of the PARFILE parameter and other parameters on the command line determines which parameters take precedence. For example, assume the parameter file params.dat contains the parameter INDEXES=y and Export is invoked with the following line: exp PARFILE=params.dat INDEXES=n In this case, because INDEXES=n occurs after PARFILE=params.dat, INDEXES=n overrides the value of the INDEXES parameter in the parameter file. Interactive Mode If you prefer to be prompted for the value of each parameter, you can simply specify either exp or imp at the command line. You will be prompted for a username and password. Commonly used parameters are then displayed. You can accept the default value, if one is provided, or enter a different value. The command-line interactive method does not provide prompts for all functionality and is provided only for backward compatibility. If you want to use an interactive interface, Oracle recommends that you use the Oracle Enterprise Manager Export or Import Wizard.
5.4. Restrictions When Using Export's Interactive Method

Keep in mind the following points when you use the interactive method: In user mode, Export prompts for all usernames to be included in the export before exporting any data. To indicate the end of the user list and begin the current Export session, press Enter. In table mode, if you do not specify a schema prefix, Export defaults to the exporter's schema or the schema containing the last table exported in the current session.
For example, if beth is a privileged user exporting in table mode, Export assumes that all tables are in the beth schema until another schema is specified. Only a privileged user (someone with the EXP_FULL_DATABASE role) can export tables in another user's schema.
Page 34 of 212
5.5. Getting Online Help

Export and Import both provide online help. Enter exp help=y on the command line to invoke Export help or imp help=y to invoke Import help.
5.6. Importing Grants

To import the privileges that a user has granted to others, the user initiating the import must either own the objects or have object privileges with the WITH GRANT OPTION.
5.6.1. Grant Conditions

Object privileges the object must exist in the user's schema, or the user must have the object privileges with the WITH GRANT OPTION or, the user must have the IMP_FULL_DATABASE role enabled. System privileges User must have the SYSTEM privilege as well as the WITH ADMIN OPTION.
5.7. Importing Objects into Other Schemas

To import objects into another user's schema, you must have the IMP_FULL_DATABASE role enabled.
5.7.1. Importing System Objects

To import system objects from a full database export file, the IMP_FULL_DATABASE role must be enabled. The parameter FULL specifies that the following system objects are included in the import when the export file is a full export: Profiles Public database links Public synonyms Roles Rollback segment definitions Resource costs Foreign function libraries Context objects System procedural objects System audit options System privileges Tablespace definitions Tablespace quotas User definitions Directory aliases System event triggers Processing Restrictions
The following restrictions apply when you process data with the Export and Import utilities:
Page 35 of 212
When a type definition has evolved and then data referencing that evolved type is exported, the type definition on the import system must have evolved in the same manner. The table compression attribute of tables and partitions is preserved during export and import. However, the import process does not use the direct path API, hence the data will not be stored in the compressed format when imported.
5.7.2. Table Objects: Order of Import

Table objects are imported as they are read from the export file. The export file contains objects in the following order: 1. Type definitions 2. Table definitions 3. Table data 4. Table indexes 5. Integrity constraints, views, procedures, and triggers 6. Bitmap, function-based, and domain indexes The order of import is as follows: new tables are created, data is imported and indexes are built, triggers are imported, integrity constraints are enabled on the new tables, and any bitmap, function-based, and/or domain indexes are built. This sequence prevents data from being rejected due to the order in which tables are imported. This sequence also prevents redundant triggers from firing twice on the same data (once when it is originally inserted and again during the import). For example, if the emp table has a referential integrity constraint on the dept table and the emp table is imported first, all emp rows that reference departments that have not yet been imported into dept would be rejected if the constraints were enabled. When data is imported into existing tables, however, the order of import can still produce referential integrity failures. In the situation just given, if the emp table already existed and referential integrity constraints were in force, many rows could be rejected. A similar situation occurs when a referential integrity constraint on a table references itself. For example, if scott's manager in the emp table is drake, and drake's row has not yet been loaded, scott's row will fail, even though it would be valid at the end of the import. Note: For the reasons mentioned previously, it is a good idea to disable referential constraints when importing into an existing table. You can then reenable the constraints after the import is completed.
5.7.3. Importing into Existing Tables

This section describes factors to take into account when you import data into existing tables. Manually Creating Tables before Importing Data When you choose to create tables manually before importing data into them from an export file, you should use either the same table definition previously used or a compatible format. For example, although you can increase the width of columns and change their order, you cannot do the following: Add NOT NULL columns Change the datatype of a column to an incompatible datatype (LONG to NUMBER, for example) Change the definition of object types used in a table Change DEFAULT column values
Note: When tables are manually created before data is imported, the CREATE TABLE statement in the export dump file will fail because the table already exists. To avoid this failure and continue loading data into the table, set the Import parameter IGNORE=y. Otherwise, no data will be loaded into the table because of the table creation error.
5.7.4. Disabling Referential Constraints

In the normal import order, referential constraints are imported only after all tables are imported. This sequence prevents errors that could occur if a referential integrity constraint exists for data that has not yet been imported. These errors can still occur when data is loaded into existing tables. For example, if table emp has a referential integrity constraint on the mgr column that verifies that the manager number exists in emp, a legitimate employee
Page 36 of 212
row might fail the referential integrity constraint if the manager's row has not yet been imported. When such an error occurs, Import generates an error message, bypasses the failed row, and continues importing other rows in the table. You can disable constraints manually to avoid this. Referential constraints between tables can also cause problems. For example, if the emp table appears before the dept table in the export file, but a referentia l check exists from the emp table into the dept table, some of the rows from the emp table may not be imported due to a referential constraint violation. To prevent errors like these, you should disable referential integrity constraints when importing data into existing tables.
Data Pump
Page 37 of 212
6. Data Pump
Oracle Data Pump technology enables very high-speed movement of data and metadata from one data base to another.
6.1. Data Pump Components

Oracle Data Pump is made up of three distinct parts: The command-line clients, expdp and impdp The DBMS_DATAPUMP PL/SQL package (also known as the Data Pump API) The DBMS_METADATA PL/SQL package (also known as the Metadata API)
The Data Pump clients, expdp and impdp, invoke the Data Pump Export utility and Data Pump Import utility, respectively. They provide a user interface that closely resembles the original Export (exp) and Import (imp) utilities. Note: Dump files generated by the Data Pump Export utility are not compatible with dump files generated by the original Export utility. Therefore, files generated by the original Export (exp) utility cannot be imported with the Data Pump Import (impdp) utility. In most cases, Oracle recommends that you use the Data Pump Export and Import utilities. They provide enhanced data movement performance in comparison to the original Export and Import utilities. The expdp and impdp clients use the procedures provided in the DBMS_DATAPUMP PL/SQL package to execute export and import commands, using the parameters entered at the command-line. These parameters enable the exporting and importing of data and metadata for a complete database or for subsets of a database.When metadata is moved, Data Pump uses functionality provided by the DBMS_METADATA PL/SQL package. The DBMS_METADATA package provides a centralized facility for the extraction, manipulation, and resubmission of dictionary metadata. The DBMS_DATAPUMP and DBMS_METADATA PL/SQL packages can be used independently of the Data Pump clients. Note: All Data Pump Export and Import processing, including the reading and writing of dump files, is done on the system (server) selected by the specified database connect string. This means that, for non-privileged users, the database administrator (DBA) must create directory objects for the Data Pump files that are read and written on that server file system. For privileged users, a default directory object is available. Note: Data Pump Export and Import are not supported on physical or logical standby databases except for initial table instantiation on a logical standby.
6.2. How Does Data Pump Move Data?

Data Pump uses four mechanisms for moving data in and out of databases. They are as follows, in order of decreasing speed: Data file copying Direct path External tables Network link import
Note: Data Pump will not load tables with disabled unique indexes. If the data needs to be loaded into the table, the indexes must be either dropped or reenabled. Note: There are a few situations in which Data Pump will not be able to load data into a table using either direct path or external tables. This occurs when there are conflicting table attributes. For example, a conflict occurs if a table contains a column of datatype LONG (which requires the direct path access method) but also has a condition
Data Pump
Page 38 of 212
that prevents use of direct path access. In such cases, an ORA-39242 error message is generated. To work around this, prior to import, create the table with a LOB column instead of a LONG column. You can then perform the import and use the TABLE_EXISTS_ACTION parameter with a value of either APPEND or TRUNCATE.
6.2.1. Using Data File Copying to Move Data

The fastest method of moving data is to copy the database data files to the target database without interpreting or altering the data. With this method, Data Pump Export is used to unload only structural information (metadata) into the dump file. This method is used in the following situations: The TRANSPORT_TABLESPACES parameter is used to specify a transportable mode export. Only metadata for the specified tablespaces is exported. The TRANSPORTABLE=ALWAYS parameter is supplied on a table mode export (specified with the TABLES parameter). Only metadata for the tables, partitions, and subpartitions specified on the TABLES parameter is exported.
When an export operation uses data file copying, the corresponding import job always also uses data file copying. During the ensuing import operation, you will be loading both the data files and the export dump file. When data is moved by using data file copying, the character sets must be identical on both the source and target databases. Therefore, in addition to copying the data, you may need to prepare it by using the Recovery Manager (RMAN) CONVERT command to perform some data conversions. You can generally do this at either the source or target database.
6.2.2. Using Direct Path to Move Data

After data file copying, direct path is the fastest method of moving data. In this method, the SQL layer of the database is bypassed and rows are moved to and from the dump file with only minimal interpretation. Data Pump automatically uses the direct path method for loading and unloading data when the structure of a table allows it. Note that if the table has any columns of datatype LONG, then direct path must be used. The following sections describe situations in which direct path cannot be used for loading and unloading.
6.2.3. Situations in Which Direct Path Load Is Not Used

If any of the following conditions exist for a table, Data Pump uses external tables rather than direct path to load the data for that table: A global index on multipartition tables exists during a single-partition load. This includes object tables that are partitioned. A domain index exists for a LOB column. A table is in a cluster. There is an active trigger on a pre-existing table. Fine-grained access control is enabled in insert mode on a pre-existing table. A table contains BFILE columns or columns of opaque types. A referentia l integrity constraint is present on a pre-existing table. A table contains VARRAY columns with an embedded opaque type. The table has encrypted columns The table into which data is being imported is a pre-existing table and at least one of the following conditions exists: There is an active trigger The table is partitioned Fine-grained access control is in insert mode A referentia l integrity constraint exists A unique index exists Supplemental logging is enabled and the table has at least one LOB column. The Data Pump command for the specified table used the QUERY, SAMPLE, or REMAP_DATA parameter.
6.2.4. Situations in Which Direct Path Unload Is Not Used

If any of the following conditions exist for a table, Data Pump uses the external table method to unload data, rather than direct path: Fine-grained access control for SELECT is enabled. The table is a queue table.
Data Pump
Page 39 of 212
The table contains one or more columns of type BFILE or opaque, or an object type containing opaque columns. The table contains encrypted columns. The table contains a column of an evolved type that needs upgrading. The table contains a column of type LONG or LONG RAW that is not last. The Data Pump command for the specified table used the QUERY, SAMPLE, or REMAP_DATA parameter.
6.2.5. Using Network Link Import to Move Data

When the Import NETWORK_LINK parameter is used to specify a network link for an import operation, SQL is directly used to move the data using an INSERT SELECT statement. The SELECT clause retrieves the data from the remote database over the network link. The INSERT clause uses SQL to insert the data into the target database. There are no dump files involved. When you perform an export over a database link, the data from the source database instance is written to dump files on the connected database instance. The source database can be a read-only database. Because the link can identify a remotely networked database, the terms database link and network link are used interchangeably. Because reading over a network is generally slower than reading from a disk, network link is the slowest of the four access methods used by Data Pump and may be undesirable for very large jobs. Supported Link Types The following types of database links are supported for use with Data Pump Export and Import: Public (both public and shared) Fixed-user Connected user
Unsupported Link Types The database link type, Current User, is not supported for use with Data Pump Export or Import:
6.3. Process during execution of a DATAPUMP job

Data Pump jobs use a master table, a master process, and worker processes to perform the work and keep track of progress.
6.3.1. Coordination of a Job

For every Data Pump Export job and Data Pump Import job, a master process is created. The master process controls the entire job, including communicating with the clients, creating and controlling a pool of worker processes, and performing logging operations.
6.3.2. Tracking Progress within a Job

While the data and metadata are being transferred, a master table is used to track the progress within a job. The master table is implemented as a user table within the database. The specific function of the master table for export and import jobs is as follows: For export jobs, the master table records the location of database objects within a dump file set. Export builds and maintains the master table for the duration of the job. At the end of an export job, the content of the master table is written to a file in the dump file set. For import jobs, the master table is loaded from the dump file set and is used to control the sequence of operations for locating objects that need to be imported into the target database.
The master table is created in the schema of the current user performing the export or import operation. Therefore, that user must have the CREATE TABLE system privilege and a sufficient tablespace quota for creation of the master table. The name of the master table is the same as the name of the job that created it. Therefore, you cannot explicitly give a Data Pump job the same name as a preexisting table or view. For all operations, the information in the master table is used to restart a job. The master table is either retained or dropped, depending on the circumstances, as follows:
Data Pump
Page 40 of 212
Upon successful job completion, the master table is dropped. If a job is stopped using the STOP_JOB interactive command, the master table is retained for use in restarting the job. If a job is killed using the KILL_JOB interactive command, the master table is dropped and the job cannot be restarted. If a job terminates unexpectedly, the master table is retained. You can delete it if you do not intend to restart the job. If a job stops before it starts running (that is, before any database objects have been copied), the master table is dropped.
6.3.3. Filtering Data and Metadata during a Job

Within the master table, specific objects are assigned attributes such as name or owning schema. Objects also belong to a class of objects (such as TABLE, INDEX, or DIRECTORY). The class of an object is called its object type. You can use the EXCLUDE and INCLUDE parameters to restrict the types of objects that are exported and imported. The objects can be based upon the name of the object or the name of the schema that owns the object. You can also specify data-specific filters to restrict the rows that are exported and imported.
6.3.4. Transforming Metadata during a Job

When you are moving data from one database to another, it is often useful to perform transformations on the metadata for remapping storage between tablespaces or redefining the owner of a particular set of objects. This is done using the following Data Pump Import parameters: REMAP_DATAFILE, REMAP_SCHEMA, REMAP_TABLE, REMAP_TABLESPACE, TRANSFORM and PARTITION_ OPTIONS.
6.3.5. Maximizing Job Performance

Data Pump can employ multiple worker processes, running in parallel, to job increase performance. Use the PARALLEL parameter to set a degree of parallelism that takes maximum advantage of current conditions. For example, to limit the effect of a job on a production system, the database administrator (DBA) might wish to restrict the parallelism. The degree of parallelism can be reset at any time during a job. For example, PARALLEL could be set to 2 during production hours to restrict a particular job to only two degrees of parallelism, and during nonproduction hours it could be reset to 8. The parallelism setting is enforced by the master process, which allocates work to be executed to worker processes that perform the data and metadata processing within an operation. These worker processes operate in parallel. In general, the degree of parallelism should be set to no more than twice the number of CPUs on an instance. Note: The ability to adjust the degree of parallelism is available only in the Enterprise Edition of Oracle Database.
6.3.6. Loading and Unloading of Data

The worker processes are the ones that actually unload and load metadata and table data in parallel. Worker processes are created as needed until the number of worker processes is equal to the value supplied for the PARALLEL command-line parameter. The number of active worker processes can be reset throughout the life of a job. Note: The value of PARALLEL is restricted to 1 in the Standard Edition of Oracle Database. When a worker process is assigned the task of loading or unloading a very large table or partition, it may choose to use the external tables access method to make maximum use of parallel execution. In such a case, the worker process becomes a parallel execution coordinator. The actual loading and unloading work is divided among some number of parallel I/O execution processes (sometimes called slaves) allocated from the Oracle RAC-wide pool of parallel I/O execution processes.
6.3.7. Monitoring Job Status

The Data Pump Export and Import utilities can be attached to a job in either interactive-command mode or logging mode. In logging mode, real-time detailed status about the job is automatically displayed during job execution. The information displayed can include the job and parameter descriptions, an estimate of the amount of data to be exported, a description of the current operation or item being processed, files used during the job, any errors encountered, and the final job state (Stopped or Completed).
Data Pump
Page 41 of 212
Job status can be displayed on request in interactive-command mode. The information displayed can include the job description and state, a description of the current operation or item being processed, files being written, and a cumulative status. An alternative way to determine job status or to get other information about Data Pump jobs, would be to query the DBA_DATAPUMP_JOBS, USER_DATAPUMP_JOBS, or DBA_DATAPUMP_SESSIONS views.
6.3.8. Monitoring the Progress of Executing Jobs

Data Pump operations that transfer table data (export and import) maintain an entry in the V$SESSION_LONGOPS dynamic performance view indicating the job progress (in megabytes of table data transferred). The entry contains the estimated transfer size and is periodically updated to reflect the actual amount of data transferred. Use of the COMPRESSION, ENCRYPTION, ENCRYPTION_ALGORITHM, ENCRYPTION_MODE, ENCRYPTION_ PASSWORD, QUERY, REMAP_DATA, and SAMPLE parameters will not be reflected in the determination of estimate values. The usefulness of the estimate value for export operations depends on the type of estimation requested when the operation was initiated, and it is updated as required if exceeded by the actual transfer amount. The estimate value for import operations is exact. The V$SESSION_LONGOPS columns that are relevant to a Data Pump job are as follows: USERNAME - job owner OPNAME - job name TARGET_DESC - job operation SOFAR - megabytes (MB) transferred thus far during the job TOTALWORK - estimated number of megabytes (MB) in the job UNITS - 'MB' MESSAGE - a formatted status message of the form: 'job_name: operation_name : nnn out of mmm MB done'
6.4. File Allocation

Data Pump jobs manage the following types of files: Dump files to contain the data and metadata that is being moved Log files to record the messages associated with an operation SQL files to record the output of a SQLFILE operation. A SQLFILE operation is invoked using the Data Pump Import SQLFILE parameter and results in all of the SQL DDL that Import will be executing based on other parameters, being written to a SQL file. Files specified by the DATA_FILES parameter during a transportable import.
An understanding of how Data Pump allocates and handles these files will help you to use Export and Import to their fullest advantage.
6.4.1. Specifying Files and Adding Additional Dump Files

For export operations, you can specify dump files at the time the job is defined, as well as at a later time during the operation. For example, if you discover that space is running low during an export operation, you can add additional dump files by using the Data Pump Export ADD_FILE command in interactive mode. For import operations, all dump files must be specified at the time the job is defined. Log files and SQL files will overwrite previously existing files. For dump files, you can use the Export REUSE_DUMPFILES parameter to specify whether or not to overwrite a preexisting dump file.
6.4.2. Default Locations for Dump, Log, and SQL Files

Because Data Pump is server-based, rather than client-based, dump files, log files, and SQL files are accessed relative to server-based directory paths. Data Pump requires you to specify directory paths as directory objects. A directory object maps a name to a directory path on the file system. For example, the following SQL statement creates a directory object named dpump_dir1 that is mapped to a directory located at /usr/apps/datafiles. SQL> CREATE DIRECTORY dpump_dir1 AS '/usr/apps/datafiles';
Data Pump The reason that a directory object is required is to ensure data security and integrity. For example:
Page 42 of 212
If you were allowed to specify a directory path location for an input file, you might be able to read data that the server has access to, but to which you should not. If you were allowed to specify a directory path location for an output file, the server might overwrite a file that you might not normally have privileges to delete.
On UNIX and Windows NT systems, a default directory object, DATA_PUMP_DIR, is created at database creation or whenever the database dictionary is upgraded. By default, it is available only to privileged users. If you are not a privileged user, before you can run Data Pump Export or Data Pump Import, a directory object must be created by a database administrator (DBA) or by any user with the CREATE ANY DIRECTORY privilege. After a directory is created, the user creating the directory object needs to grant READ or WRITE permission on the directory to other users. For example, to allow the Oracle database to read and write files on behalf of user hr in the directory named by dpump_dir1, the DBA must execute the following command: SQL> GRANT READ, WRITE ON DIRECTORY dpump_dir1 TO hr; Note that READ or WRITE permission to a directory object only means that the Oracle database will read or write that file on your behalf. You are not given direct access to those files outside of the Oracle database unless you have the appropriate operating system privileges. Similarly, the Oracle database requires permission from the operating system to read and write files in the directories. Data Pump Export and Import use the following order of precedence to determine a file's location: 1. If a directory object is specified as part of the file specification, then the location specified by that directory object is used. (The directory object must be separated from the filename by a colon.) 2. If a directory object is not specified for a file, then the directory object named by the DIRECTORY parameter is used. 3. If a directory object is not specified, and if no directory object was named by the DIRECTORY parameter, then the value of the environment variable, DATA_PUMP_DIR, is used. This environment variable is defined using operating system commands on the client system where the Data Pump Export and Import utilities are run. The value assigned to this client-based environment variable must be the name of a server-based directory object, which must first be created on the server system by a DBA. For example, the following SQL statement creates a directory object on the server system. The name of the directory object is DUMP_FILES1, and it is located at '/usr/apps/dumpfiles1'. SQL> CREATE DIRECTORY DUMP_FILES1 AS '/usr/apps/dumpfiles1'; Then, a user on a UNIX-based client system using csh can assign the value DUMP_FILES1 to the environment variable DATA_PUMP_DIR. The DIRECTORY parameter can then be omitted from the command line. The dump file employees.dmp, as well as the log file export.log, will be written to '/usr/apps/dumpfiles1'. %setenv DATA_PUMP_DIR DUMP_FILES1 %expdp hr TABLES=employees DUMPFILE=employees.dmp 4. If none of the previous three conditions yields a directory object and you are a privileged user, then Data Pump attemp ts to use the value of the default server-based directory object, DATA_PUMP_DIR. This directory object is automatically created at database creation or when the database dictionary is upgraded. You can use the following SQL query to see the path definition for DATA_PUMP_DIR: SQL> SELECT directory_name, directory_path FROM dba_directories 2 WHERE directory_name=DATA_PUMP_DIR; If you are not a privileged user, access to the DATA_PUMP_DIR directory object must have previously been granted to you by a DBA. Do not confuse the default DATA_PUMP_DIR directory object with the client-based environment variable of the same name.
Data Pump
Page 43 of 212
6.5. Setting Parallelism

For export and import operations, the parallelism setting (specified with the PARALLEL parameter) should be less than or equal to the number of dump files in the dump file set. If there are not enough dump files, the performance will not be optimal because multiple threads of execution will be trying to access the same dump file. The PARALLEL parameter is valid only in the Enterprise Edition of Oracle Database.
6.6. Using Substitution Variables

Instead of, or in addition to, listing specific filenames, you can use the DUMPFILE parameter during export operations to specify multiple dump files, by using a substitution variable (%U) in the filename. This is called a dump file template. The new dump files are created as they are needed, beginning with 01 for %U, then using 02, 03, and so on. Enough dump files are created to allow all processes specified by the current setting of the PARALLEL parameter to be active. If one of the dump files becomes full because its size has reached the maximum size specified by the FILESIZE parameter, it is closed, and a new dump file (with a new generated name) is created to take its place. If multiple dump file templates a re provided, they are used to generate dump files in a round-robin fashion. For example, if expa%U, expb%U, and expc%U were all specified for a job having a parallelism of 6, the initial dump files created would be expa01.dmp, expb01.dmp, expc01.dmp, expa02.dmp, expb02.dmp, and expc02.dmp. For import and SQLFILE operations, if dump file specifications expa%U, expb%U, and expc%U are specified, then the operation will begin by attempting to open the dump files expa01.dmp, expb01.dmp, and expc01.dmp. It is possible for the master table to span multiple dump files, so until all pieces of the master table are found, dump files continue to be opened by incrementing the substitution variable and looking up the new filenames (for example, expa02.dmp, expb02.dmp, and expc02.dmp). If a dump file does not exist, the operation stops incrementing the substitution variable for the dump file specification that was in error. For example, if expb01.dmp and expb02.dmp are found but expb03.dmp is not found, then no more files are searched for using the expb%U specification. Once the entire master table is found, it is used to determine whether all dump files in the dump file set have been located.
6.7. Moving Data between Different Database Versions

Because most Data Pump operations are performed on the server side, if you are using any version of the database other than COMPATIBLE, you must provide the server with specific version information. Otherwise, errors may occur. To specify version information, use the VERSION parameter. Keep the following information in mind when you are using Data Pump Export and Import to move data between different database versions: If you specify a database version that is older than the current database version, certain features may be unavailable. For example, specifying VERSION=10.1 will cause an error if data compression is also specified for the job because compression was not supported in 10.1. On a Data Pump export, if you specify a database version that is older than the current database version, then a dump file set is created that you can import into that older version of the database. However, the dump file set will not contain any objects that the older database version does not support. For example, if you export from a version 10.2 database to a version 10.1 database, comments on indextypes will not be exported into the dump file set. Data Pump Import can always read dump file sets created by older versions of the database. Data Pump Import cannot read dump file sets created by a database version that is newer than the current database version, unless those dump file sets were created with the version parameter set to the version of the target database. Therefore, the best way to perform a downgrade is to perform your Data Pump export with the VERSION parameter set to the version of the target database. When operating across a network link, Data Pump requires that the remote database version be either the same as the local database or one version older, at the most. For example, if the local database is version
Data Pump 11.1, the remote database must be either version 10.2 or 11.1.
Page 44 of 212
6.8. Data Pump Export

Note: Although Data Pump Export (expdp) functionality is similar to that of the original Export utility (exp), they are completely separate utilities and their files are not compatible. Data Pump Export (hereinafter referred to as Export for ease of reading) is a utility for unloading data and metadata into a set of operating system files called a dump file set. The dump file set can be imported only by the Data Pump Imp ort utility. The dump file set can be imported on the same system or it can be moved to another system and loaded there. The dump file set is made up of one or more disk files that contain table data, database object metadata, and control information. The files are written in a proprietary, binary format. During an import operation, the Data Pump Import utility uses these files to locate each database object in the dump file set. Because the dump files are written by the server, rather than by the client, the data base administrator (DBA) must create directory objects. See Default Locations for Dump, Log, and SQL Files on page 1-10 for more information about directory objects. Data Pump Export enables you to specify that a job should move a subset of the data and metadata, as determined by the export mode. This is done using data filters and metadata filters, which are specified through Export parameters.
6.8.1. Invoking Data Pump Export

The Data Pump Export utility is invoked using the expdp command. The characteristics of the export operation are determined by the Export parameters you specify. These parameters can be specified either on the command line or in a parameter file. Note: Do not invoke Export as SYSDBA, except at the request of Oracle technical support. SYSDBA is used internally and has specialized functions; its behavior is not the same as for general users. Note: It is not possible to start or restart Data Pump jobs on one instance in an Oracle Real Application Clusters (RAC) environment if there are Data Pump jobs currently running on other instances in the Oracle RAC environment.
6.8.2. Data Pump Export Interfaces

You can interact with Data Pump Export by using a command line, a parameter file, or an interactivecommand mode. Command-Line Interface: Enables you to specify most of the Export parameters directly on the command line. Parameter File Interface: Enables you to specify command-line parameters in a parameter file. The only exception is the PARFILE parameter, because parameter files cannot be nested. The use of parameter files is recommended if you are using parameters whose values require quotation marks. Interactive-Command Interface: Stops logging to the terminal and displays the Export prompt, from which you can enter various commands, some of which are specific to interactive-command mode. This mode is enabled by pressing Ctrl+C during an export operation started with the command-line interface or the parameter file interface. Interactive-command mode is also enabled when you attach to an executing or stopped job.
6.8.3. Data Pump Export Modes

Export provides different modes for unloading different portions of the database. The mode is specified on the command line, using the appropriate parameter. The available modes are as follows: Note: A number of system schemas cannot be exported because they are not user schemas; they contain Oraclemanaged data and metadata. Examples of system schemas that are not exported include SYS, ORDSYS, and MDSYS. Schema Mode
Data Pump
Page 45 of 212
A schema export is specified using the SCHEMAS parameter. This is the default export mode. If you have the EXP_FULL_DATABASE role, then you can specify a list of schemas and optionally include the schema definitions themselves, as well as system privilege grants to those schemas. If you do not have the EXP_FULL_DATABASE role, you can export only your own schema. The SYS schema cannot be used as a source schema for export jobs. Cross-schema references are not exported unless the referenced schema is also specified in the list of schemas to be exported. For example, a trigger defined on a table within one of the specified schemas, but that resides in a schema not explicitly specified, is not exported. This is also true for external type definitions upon which tables in the specified schemas depend. In such a case, it is expected that the type definitions already exist in the target instance at import time. Table Mode A table mode export is specified using the TABLES parameter. In table mode, only a specified set of tables, partitions, and their dependent objects are unloaded. If you specify the TRANSPORTABLE=ALWAYS parameter in conjunction with the TABLES parameter, then only object metadata is unloaded. To move the actual data, you copy the data files to the target database. This results in quicker export times. If you are moving data files between versions or platforms, the data files may need to be processed by Oracle Recovery Manager (RMAN). You must have the EXP_FULL_DATABASE role to specify tables that are not in your own schema. All specified tables must reside in a single schema. Note that type definitions for columns are not exported in table mode. It is expected that the type definitions already exist in the target instance at import time. Also, as in schema exports, cross-schema references are not exported. Tablespace Mode A tablespace export is specified using the TABLESPACES parameter. In tablespace mode, only the tables contained in a specified set of tablespaces are unloaded. If a table is unloaded, its dependent objects are also unloaded. Both object metadata and data are unloaded. In tablespace mode, if any part of a table resides in the specified set, then that table and all of its dependent objects are exported. Privileged users get all tables. Nonprivileged users get only the tables in their own schemas. Transportable Tablespace Mode A transportable tablespace export is specified using the TRANSPORT_TABLESPACES parameter. In transportable tablespace mode, only the metadata for the tables (and their dependent objects) within a specified set of tablespaces is exported. The tablespace datafiles are copied in a separate operation. Then, a transportable tablespace import is performed to import the dump file containing the metadata and to specify the datafiles to use. Transportable tablespace mode requires that the specified tables be completely self-contained. That is, all storage segments of all tables (and their indexes) defined within the tablespace set must also be contained within the set. If there are self-containment violations, Export identifies all of the problems without actually performing the export. Transportable tablespace exports cannot be restarted once stopped. Also, they cannot have a degree of parallelism greater than 1.Encrypted columns are not supported in transportable tablespace mode. Note: You cannot export transportable tablespaces and then import them into a database at a lower release level. The target database must be at the same or higher release level as the source database.
6.8.4. Filtering During Export Operations

You can specify a connect identifier in the connect string when you invoke the Data Pump Export utility. This identifier can specify a database instance that is different from the current instance identified by the current Oracle System ID (SID). The connect identifier can be an Oracle*Net connect descriptor or a name that maps to a connect descriptor. This requires an active listener (to start the listener, enter lsnrctl start) that can be located using the connect descriptor. The following example invokes Export for user hr, using the connect descriptor named inst1: expdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp TABLES=employees Export: Release 11.1.0.6.0 - Production on Monday, 27 August, 2007 10:15:45 Copyright (c) 2003, 2007, Oracle. Password: password@inst1 Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 www.wilshiresoft.com info@wilshiresoft.com Wilshire Software Technologies Ph: 2761-2214 / 5577-2214 Rev. Dt: 10-Oct-08 Version: 6
All rights reserved.
Data Pump Production With the Partitioning, Data Mining and Real Application Testing options
Page 46 of 212
The local Export client connects to the database instance identified by the connect descriptor inst1 (a simple net service name, usually defined in a tnsnames.ora file), to export the data on that instance. Do not confuse invoking the Export utility using a connect identifier with an export operation specifying the Export NETWORK_LINK command-line parameter. When you perform an export and use the NETWORK_LINK parameter, the export is initiated over a database link. Whereas, when you start an export operation and specify a connect identifier, the local Export client connects to the database instance identified by the command-line connect string, retrieves the data to be exported from the database instance identified by the database link, and writes the data to a dump file set on the connected database instance. Data Pump Export provides much greater data and metadata filtering capability than was provided by the original Export utility.
6.9. Data Pump Import

Note: Although Data Pump Import (impdp) functionality is similar to that of the original Import utility (imp), they are completely separate utilities and their files are not compatible. Data Pump Import (hereinafter referred to as Import for ease of reading) is a utility for loading an export dump file set into a target system. The dump file set is made up of one or more disk files that contain table data, database object metadata, and control information. The files are written in a proprietary, binary format. During an import operation, the Data Pump Import utility uses these files to locate each database object in the dump file set. Import can also be used to load a target database directly from a source database with no intervening dump files. This is known as a network import. Data Pump Import enables you to specify whether a job should move a subset of the data and metadata from the dump file set or the source database (in the case of a network import), as determined by the import mode. This is done using data filters and metadata filters, which are implemented through Import commands.
6.9.1. Invoking Data Pump Import

The Data Pump Import utility is invoked using the impdp command. The characteristics of the import operation are determined by the import parameters you specify. These parameters can be specified either on the command line or in a parameter file. Note: Do not invoke Import as SYSDBA, except at the request of Oracle technical support. SYSDBA is used internally and has specialized functions; its behavior is not the same as for general users. Note: Be aware that if you are performing a Data Pump Import into a table or tablespace created with the NOLOGGING cla use enabled, a redo log file may still be generated. The redo that is generated in such a case is generally for maintenance of the master table or related to underlying recursive space transactions, data dictionary changes, and index maintenance for indices on the table that require logging. Note: It is not possible to start or restart Data Pump jobs on one instance in an Oracle Real Application Clusters (RAC) environment if there are Data Pump jobs currently running on other instances in the Oracle RAC environment.
6.9.2. Data Pump Import Interfaces

You can interact with Data Pump Import by using a command line, a parameter file, or an interactivecommand mode. Command-Line Interface: Enables you to specify the Import parameters directly on the command line. Parameter File Interface: Enables you to specify command-line parameters in a parameter file. The only exception is the PARFILE parameter because parameter files cannot be nested. The use of parameter files is recommended if you are using parameters whose values require quotation marks. Interactive-Command Interface: Stops logging to the terminal and displays the Import prompt, from which you can enter various commands, some of which are specific to interactive-command mode. This mode is enabled by pressing Ctrl+C during an import operation started with the command-line interface or the
Data Pump
Page 47 of 212
parameter file interface. Interactive-command mode is also enabled when you attach to an executing or stopped job.
6.9.3. Data Pump Import Modes

One of the most significant characteristics of an import operation is its mode, because the mode largely determines what is imported. The specified mode applies to the source of the operation, either a dump file set or another data base if the NETWORK_LINK parameter is specified. When the source of the import operation is a dump file set, specifying a mode is optional. If no mode is specified, then Import attempts to load the entire dump file set in the mode in which the export operation was run. The mode is specified on the command line, using the appropriate parameter. The available modes are as follows: Full Import Mode Schema Mode Table Mode Tablespace Mode Transportable Tablespace Mode
Note: When you import a dump file that was created by a full-mode export, the import operation attempts to copy the password for the SYS account from the source database. This sometimes fails (for example, if the password is in a shared password file). If it does fail, then after the import completes, you must set the password for the SYS account at the target database to a password of your choice. Note: Jobs (created by the Oracle Database job scheduler) are always imported to the schema of the importing user. After an import, if you query the DBA_JOBS view you will see that LOG_USER and PRIV_USER values are set to the importing user, regardless of how they were set on the export platform. To work around this, you must perform both the export and the import as the job owner. Full Import Mode A full import is specified using the FULL parameter. In full import mode, the entire content of the source (dump file set or another database) is loa ded into the target database. This is the default for file-based imports. You must have the IMP_FULL_DATABASE role if the source is another database. Cross-schema references are not imported for non-privileged users. For example, a trigger defined on a table within the importing user's schema, but residing in another user's schema, is not imported. The IMP_FULL_DATABASE role is required on the target database and the EXP_FULL_DATABASE role is required on the source database if the NETWORK_LINK parameter is used for a full import. Schema Mode A schema import is specified using the SCHEMAS parameter. In a schema import, only objects owned by the specified schemas are loaded. The source can be a full, table, tablespace, or schema-mode export dump file set or another database. If you have the IMP_FULL_DATABASE role, then a list of schemas can be specified and the schemas themselves (including system privilege grants) are created in the database in addition to the objects contained within those schemas. Cross-schema references are not imported for non-privileged users unless the other schema is remapped to the current schema. For example, a trigger defined on a table within the importing user's schema, but residing in another user's schema, is not imported. Table Mode A table-mode import is specified using the TABLES parameter. In table mode, only the specified set of tables, partitions, and their dependent objects are loaded. The source can be a full, schema, tablespace, or table-mode export dump file set or another database. You must have the IMP_FULL_DATABASE role to specify tables that are not in your own schema. You can use the transportable option during a table-mode import by specifying the TRANPORTABLE=ALWAYS parameter in conjunction with the TABLES parameter. Note that this requires use of the NETWORK_LINK parameter, as well. Tablespace Mode A tablespace-mode import is specified using the TABLESPACES parameter. In tablespace mode, all objects contained within the specified set of tablespaces are loaded, along with the dependent objects. The source can be a
Data Pump
Page 48 of 212
full, schema, tablespace, or table-mode export dump file set or another database. For unprivileged users, objects not remapped to the current schema will not be processed.
Transportable Tablespace Mode A transportable tablespace import is specified using the TRANSPORT_TABLESPACES parameter. In transportable tablespace mode, the metadata from a transportable tablespace export dump file set or from another database is loaded. The datafiles, specified by the TRANSPORT_DATAFILES parameter, must be made available from the source system for use in the target database, typically by copying them over to the target system. Encrypted columns are not supported in transportable tablespace mode. This mode requires the IMP_FULL_DATABASE role. Note: You cannot export transportable tablespaces and then import them into a database at a lower release level. The target database must be at the same or higher release level as the source database. Network Considerations You can specify a connect identifier in the connect string when you invoke the Data Pump Import utility. This identifier can specify a database instance that is different from the current instance identified by the current Oracle System ID (SID). The connect identifier can be an Oracle*Net connect descriptor or a name that maps to a connect descriptor. This requires an active listener (to start the listener, enter lsnrctl start) that can be located using the connect descriptor. The following example invokes Import for user hr, using the connect descriptor named inst1: > impdp hr DIRECTORY=dpump_dir1 DUMPFILE=hr.dmp TABLES=employees Import: Release 11.1.0.6.0 - Production on Monday, 27 August, 2007 12:25:57 Copyright (c) 2003, 2007, Oracle. Password: password@inst1 Connected to: Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 Production The local Import client connects to the database instance identified by the connect descriptor inst1 (a simple net service name, usually defined in a tnsnames.ora file), to import the data from the dump file set to that database. Do not confuse invoking the Import utility using a connect identifier with an import operation specifying the Import NETWORK_LINK command-line parameter, which initiates an import using a database link. In this case, the local Import client connects to the database instance identified by the command-line connect string, retrieves the data to be imported from the database instance identified by the database link, and writes the data to the connected database instance. There is no dump file set involved. Data Pump Import provides much greater data and metadata filtering capability than was provided by the original Import utility. All rights reserved.
Introduction to Backup and Recovery
Page 49 of 212
7. Introduction to Backup and Recovery

7.1. Purpose of Backup and Recovery
As a backup administrator, your principal duty is to devise, implement, and manage a backup and recovery strategy. In general, the purpose of a backup and recovery strategy is to protect the database against data loss and reconstruct the database after data loss. Typically, backup administration tasks include the following: Planning and testing responses to different kinds of failures Configuring the database environment for backup and recovery Setting up a backup schedule Monitoring the backup and recovery environment Troubleshooting backup problems Recovering from data loss if the need arises
As a backup administrator, you may also be asked to perform other duties that are related to backup and recovery: Data preservation, which involves creating a database copy for long-term storage Data transfer, which involves moving data from one database or one host to another The purpose of this manual is to explain how to perform the preceding tasks.
7.1.1. Data Protection

As a backup administrator, your primary job is making and monitoring backups for data protection. A backup is a copy of data of a database that you can use to reconstruct data. A backup can be either a physical backup or a logical backup. Physical backups are copies of the physical files used in storing and recovering a database. These files include datafiles, control files, and archived redo logs. Ultimately, every physical backup is a copy of files that store database information to another location, whether on disk or on offline storage media such as tape. Logical backups contain logical data such as tables and stored procedures. You can use the Oracle Data Pump to export logical data to binary files, which you can later import into the database. The Data Pump command-line clients expdp and impdp use the DBMS_DATAPUMP and DBMS_METADATA PL/SQL packages. Physical backups are the foundation of any sound backup and recovery strategy. Logical backups are a useful supplement to physical backups in many circumstances but are not sufficient protection against data loss without physical backups. Unless otherwise specified, the term backup as used in the backup and recovery documentation refers to a physical backup. Backing up a database is the act of making a physical backup. The focus in the backup and recovery documentation set is almost exclusively on physical backups. While several problems can halt the normal operation of an Oracle database or affect database I/O operations, only the following typically require DBA intervention and data recovery: media failure, user errors, and application errors. Other failures may require DBA intervention without causing data loss or requiring recovery from backup. For example, you may need to restart the database after an instance failure or allocate more disk space after statement failure because of a full datafile.
7.1.2. Media Failures

A media failure is a physical problem with a disk that causes a failure of a read or write of a disk file required to run the database. Any database file can be vulnerable to a media failure. The appropriate recovery technique following a media failure depends on the files affected and the types of backup available. One particularly important aspect of backup and recovery is developing a disaster recovery strategy to protect against catastrophic data loss, for example, the loss of an entire database host.
Page 50 of 212
7.1.3. User Errors

User errors occur when, either due to an error in application logic or a manual mistake, data in a database is changed or deleted incorrectly. User errors are estimated to be the greatest single cause of database downtime. Data loss due to user error can be either localized or widespread. An example of localized damage is deleting the wrong SMITH from the employees table. This type of damage requires surgical detection and repair. An example of widespread damage is a batch job that deletes the company orders for the current month. In this case, drastic action is required to avoid a extensive database downtime. While user training and careful management of privileges can prevent most user errors, your backup strategy determines how gracefully you recover the lost data when user error does cause data loss.
7.1.4. Application Errors

Sometimes a software malfunction can corrupt data blocks. In a physical corruption, which is also called a media corruption, the database does not recognize the block at all: the checksum is invalid, the block contains all zeros, or the header and footer of the block do not match. If the corruption is not extensive, then you can often repair it easily with block media recovery.
7.1.5. Data Preservation

Data preservation is related to data protection, but serves a different purpose. For example, you may need to preserve a copy of a database as it existed at the end of a business quarter. This backup is not part of the disaster recovery strategy. The media to which these backups are written are often unavailable after the backup is complete. You may send the tape into fire storage or ship a portable hard drive to a testing facility. RMAN provides a convenient way to create a backup and exempt it from your backup retention policy. This type of backup is known as an archival backup.
7.1.6. Data Transfer

In some situations you may need to take a backup of a database or database component and move it to another location. For example, you can use Recovery Manager (RMAN) to create a database copy, create a tablespace copy that can be imported into another database, or move an entire database from one platform to another. These tasks are not strictly speaking part of a backup and recovery strategy, but they do require the use of database backups, and so may be included in the duties of a backup administrator. When implementing a backup and recovery strategy, you have the following solutions available:
7.1.7. Recovery Manager (RMAN)

This tool integrates with sessions running on an Oracle database to perform a range of backup and recovery activities, including maintaining an RMAN repository of historical data about backups. You can access RMAN through the command line or through Oracle Enterprise Manager.
7.1.8. User-managed backup and recovery

In this solution, you perform backup and recovery with a mixture of host operating system commands and SQL*Plus recovery commands. Both of the preceding solutions are supported by Oracle and are fully documented, but RMAN is the preferred solution for database backup and recovery. RMAN performs the same types of backup and recovery available through user-managed techniques more easily, provides a common interface for backup tasks across different host operating systems, and offers a number of backup techniques not available through user-managed methods. RMAN gives you access to several backup and recovery techniques and features not available with user-managed backup and recovery. The most noteworthy are the following: Incremental backups Incremental backup stores only blocks changed since a previous backup. Thus, they provide more compact backups and faster recovery, thereby reducing the need to apply redo during datafile media recovery. If you enable block change tracking, then you can improve performance by avoiding full scans of every input datafile. You use the BACKUP INCREMENTAL command to perform incremental backups. Block media recovery
Page 51 of 212
You repair a datafile with only a small number of corrupt data blocks without taking it offline or restoring it from backup. You use the RECOVER command to perform block media recovery. Unused block compression In unused block compression, RMAN can skip data blocks that have never been used and, in some cases, used blocks that are currently unused. Binary compression A binary compression mechanism integrated into Oracle Database reduces the size of backups. Encrypted backups RMAN uses backup encryption capabilities integrated into Oracle Data base to store backup sets in an encrypted format. To create encrypted backups on disk, the database must use the Advanced Security Option. To create encrypted backups directly on tape, RMAN must use the Oracle Secure Backup SBT interface, but does not require the Advanced Security Option. Whether you use RMAN or user-managed methods, you can supplement physical backups with logical backups of schema objects made with Data Pump Export utility. You can later use Data Pump Import to re-create data after restore and recovery. Table summarizes the features of the different backup techniques.
7.2 Oracle Flashback Technology

As explained in Oracle Database Concepts, Oracle Flashback Technology complements your physical backup and recovery strategy. This set of features provides an additional layer of data protection. Specifically, you can use flashback features to view past states of data and rewind your database without restoring backups or performing
Page 52 of 212
point-in-time recovery. In general, flashback features are more efficient and less disruptive than media recovery in most situations in which they apply.
7.3 Logical Flashback Features

Most of the flashback features of Oracle operate at the logical level, enabling you to view and manipulate database objects. The logical-level flashback features of Oracle do not depend on RMAN and are available whether or not RMAN is part of your backup strategy. With the exception of Flashback Drop, the logical flashback features rely on undo data, which are records of the effects of each database update and the values overwritten in the update. Oracle Database includes the following logical flashback features:
7.3.1 Oracle Flashback Query

You can specify a target time and run queries against a database, viewing results as they would have appeared at the target time. To recover from an unwanted change like an update to a table, you could choose a target time before the error and run a query to retrieve the contents of the lost rows.
7.3.2 Oracle Flashback Version Query

You can view all versions of all rows that ever existed in one or more tables in a specified time interval. You can also retrieve metadata about the differing versions of the rows, including start and end time, operation, and transaction ID of the transaction that created the version. You can use this feature to recover lost data values and to audit changes to the tables queried.
7.3.3 Oracle Flashback Transaction Query

You can view changes made by a single transaction, or by all the transactions during a period of time.
7.3.4 Oracle Flashback Transaction

You can reverse a transaction. Oracle Database determines the dependencies between transactions and in effect creates a compensating transaction that reverses the unwanted changes. The database rewinds to a state as if the transaction, and any transactions that could be dependent on it, had never happened.
7.3.5 Oracle Flashback Table

You can recover a table or set of tables to a specified point in time in the past without taking any part of the database offline. In many cases, Flashback Table eliminates the need to perform more complicated point-in-time recovery operations. Flashback Table restores tables while automatically maintaining associated attributes such as current indexes, triggers, and constraints, and in this way enabling you to avoid finding and restoring databasespecific properties.
7.3.6 Oracle Flashback Drop

You can reverse the effects of a DROP TABLE statement. A flashback data archive enables you to use some of the logical flashback features to access data from far back in the past. A flashback data archive consists of one or more tablespaces or parts of tablespaces. When you create a flashback data archive, you specify the name, retention period, and tablespace. You can also specify a default flashback data archive. The database automatically purges old historical data the day after the retention period expires. You can turn flashback archiving on and off for individual tables. By default, flashback archiving is turned off for every table.
7.3.7 Flashback Database

At the physical level, Oracle Flashback Database provides a more efficient data protection alternative to database point-in-time recovery (DBPITR). If the current datafiles have unwanted changes, then you can use the RMAN command FLASHBACK DATABASE to revert the datafiles to their contents at a past time. The end product is much like the result of a DBPITR, but is generally much faster because it does not require restoring datafiles from backup and requires less redo than media recovery. Flashback Database uses flashback logs to access past versions of data blocks and some information from archived redo logs. Flashback Database requires that you configure a flash recovery area for a database because
Page 53 of 212
the flashback logs can only be stored there. Flashback logging is not enabled by default. Space used for flashback logs is managed automatically by the database and balanced against space required for other files in the flash recovery area. Oracle Database also supports restore points in conjunction with Flashback Database and backup and recovery. A restore point is an alias corresponding to an SCN. You can create a restore point at any time if you anticipate needing to return part or all of a database to its contents at that time. A guaranteed restore point ensures that you can use Flashback Database to return a database to the time of the restore point.
7.3.8 Data Recovery Advisor

Oracle Database includes a Data Recovery Advisor tool that automatically diagnoses persistent data failures, presents appropriate repair options, and executes repairs at your request. Data Recovery Advisor provides a single point of entry for Oracle backup and recovery solutions. You can use Data Recovery Advisor through the Enterprise Manager Database Control or Grid Control console or through the RMAN command-line client. A database failure usually manifests itself as a set of symptoms: error messages, alerts, trace files and dumps, and failed data integrity checks. Data Recovery Advisor automatically diagnoses and informs you of these failures. Within the context of Data Recovery Advisor, a failure is a persistent data corruption that can be directly mapped to a set of repair actions. Each failure has a status of open or closed. Each failure also has a priority of critical, high, or low. Failures are detected by data integrity checks, which are diagnostic procedures executed to assess the health of the database or its components. If a data integrity check reveals a failure, then Data Recovery Advisor automatically assesses the effect of a set of failures and maps it to a set of repair options. In most cases, Data Recovery Advisor presents both automated and manual repair options. Data Recovery Advisor determines the best automated repair option and its effect on the database. The repair option may include repairs such as datafile restore and recovery, media recovery, Flashback Database, and so on. Before presenting an automated repair option, Data Recovery Advisor validates it with respect to the specific environment and the availability of media components required completing the proposed repair. If you choose an automated repair option, then RMAN coordinates sessions on the Oracle database to perform the repair for you. The Data Recovery Advisor tool verifies the repair success and closes the approp
User Managed Database Backups
Page 54 of 212
8. User-Managed Database Backups

This chapter describes methods of backing up an Oracle database in a user-managed backup and recovery strategy, that is, a strategy that does not depend on using Recovery Manager (RMAN).
8.1 Querying V$ Views to Obtain Backup Information

Before making a backup, you must identify all the files in your database and decide what to back up. You can use V$ views to obtain this information.
8.1.1 Listing Database Files before a Backup

Use V$DATAFILE and V$CONTROLFILE to identify the data files and control files for your database. This same procedure works whether you named these files manually or allowed Oracle Managed Files to name them. To list data files and control files: 1. Start SQL*Plus and query V$DATAFILE to obtain a list of data files. For example, enter: SELECT NAME FROM V$DATAFILE; You can also join the V$TABLESPACE and V$DATAFILE views to obtain a listing of data files along with their associated tablespaces: SELECT t.NAME "Tablespace", f.NAME "Datafile" FROM WHERE V$TABLESPACE t, V$DATAFILE f t.TS# = f.TS#
ORDER BY t.NAME; 2. Obtain the filenames of the current control files by querying the V$CONTROLFILE view. For example, issue the following query: SELECT NAME FROM V$CONTROLFILE; Note that you only need to back up one copy of a multiplexed control file. 3. If you plan to take a control file backup with the ALTER DATABASE BACKUP CONTROLFILE TO 'filename' statement, then save a list of all datafiles and online redo log files with the control file backup. Because the current database structure may not match the database structure at the time a given control file backup was created, saving a list of files recorded in the backup control file can aid the recovery procedure.
8.1.2 Determining Datafile Status for Online Tablespace Backups

To check whether a datafile is part of a current online tablespace backup, query the V$BACKUP view. This view is useful only for user-managed online tablespace backups, because neither RMAN backups nor offline tablespace backups require the datafiles of a tablespace to be in backup mode. The V$BACKUP view is most useful when the database is open. It is also useful immediately after an instance failure because it shows the backup status of the files at the time of the failure. Use this information to determine whether you have left any tablespaces in backup mode. V$BACKUP is not useful if the control file currently in use is a restored backup or a new control file created after the media failure occurred. A restored or re-created control file does not contain the information the database needs to populate V$BACKUP accurately. Also, if you have restored a backup of a file, this file's STATUS in V$BACKUP reflects the backup status of the older version of the file, not the most current version. Thus, this view can contain misleading data about restored files. For example, the following query displays which datafiles are currently included in a tablespace that has been placed in backup mode: SELECT t.name AS "TB_NAME", d.file# as "DF#", d.name AS "DF_NAME", b.status FROM WHERE AND V$DATAFILE d, V$TABLESPACE t, V$BACKUP b d.TS#=t.TS# b.FILE#=d.FILE#
User Managed Database Backups AND b.STATUS='ACTIVE';
Page 55 of 212
The following sample output shows that the tools and users tablespaces currently have ACTIVE status: TB_NAME DF# DF_NAME STATUS ---------------------TOOLS USERS ---------- -------------------------------7 8 /oracle/oradata/trgt/tools01.dbf /oracle/oradata/trgt/users01.dbf -----ACTIVE ACTIVE
In the STATUS column, NOT ACTIVE indicates that the file is not currently in backup mode (that is, you have not executed the ALTER TABLESPACE ... BEGIN BACKUP or ALTER DATABASE BEGIN BACKUP statement), whereas ACTIVE indicates that the file is currently in backup mode.
8.2 Making User-Managed Backups of the Whole Database

You can make a whole database backup of all files in a database after the database has been shut down with the NORMAL, IMMEDIATE, or TRANSACTIONAL options. A whole database backup taken while the database is open or after an instance failure or SHUTDOWN ABORT is inconsistent. In such cases, the files are inconsistent with respect to the database checkpoint SCN. You can make a whole database backup if a database is operating in either ARCHIVELOG or NOARCHIVELOG mode. If you run the database in NOARCHIVELOG mode, however, then the backup must be consistent; that is, you must shut down the database cleanly before the backup. The set of backup files that results from a consistent whole database backup is consistent because all files are checkpointed to the same SCN. You can restore the consistent database backup without further recovery. After restoring the backup files, you can perform additional recovery steps to recover the database to a more current time if the database is operated in ARCHIVELOG mode. Also, you can take inconsistent whole database backups if your database is in ARCHIVELOG mode. Control files play a crucial role in database restore and recovery. For databases running in ARCHIVELOG mode, Oracle recommends that you back up control files with the ALTER DATABASE BACKUP CONTROLFILE TO 'filename' statement.
8.2.1 Making Consistent Whole Database Backups

This section describes how to back up the database with an operating system utility. To make a consistent whole database backup: 1. If the database is open, then use SQL*Plus to shut down the database with the NORMAL, IMMEDIATE, or TRANSACTIONAL options. 2. Use an operating system utility to make backups of all datafiles as well as all control files specified by the CONTROL_FILES parameter of the initialization parameter file. Also, back up the initialization parameter file and other Oracle product initialization files. To find these files, do a search for *.ora starting in your Oracle home directory and recursively search all of its subdirectories. For example, you can back up the datafiles, control files and archived logs to /disk2/backup as follows: % cp $ORACLE_HOME/oradata/trgt/*.dbf /disk2/backup % cp $ORACLE_HOME/oradata/trgt/arch/* /disk2/backup/arch 3. Restart the database with the STARTUP command in SQL*Plus.
8.3 Making User-Managed Backups of Tablespaces and Datafiles

The technique for making user-managed backups of tablespaces and datafiles depends on whether the files are offline or online.
8.3.1 Making User-Managed Backups of Offline Tablespaces and Datafiles

Note the following guidelines when backing up offline tablespaces: You cannot offline the SYSTEM tablespace or a tablespace with active undo segments. The following technique cannot be used for such tablespaces.
Page 56 of 212
Assume that a table is in tablespace Primary and its index is in tablespace Index. Taking tablespace Index offline while leaving tablespace Primary online can cause errors when DML is issued against the indexed tables located in Primary. The problem only manifests when the access method chosen by the optimizer needs to access the indexes in the Index tablespace. To back up offline tablespaces: 1. Before beginning a backup of a tablespace, identify the tablespace's datafiles by querying the DBA_DATA_FILES view. For example, assume that you want to back up the users tablespace. Enter the following statement in SQL*Plus: SELECT TABLESPACE_NAME, FILE_NAME FROM SYS.DBA_DATA_FILES WHERE TABLESPACE_NAME = 'USERS';
TABLESPACE_NAME ------------------------------USERS
FILE_NAME -------------------------------/oracle/oradata/trgt/users01.dbf
In this example, /oracle/oradata/trgt/users01.dbf is a fully specified filename corresponding to the datafile in the users tablespace. 2. Take the tablespace offline using normal priority if possible because it guarantees that you ca n subsequently bring the tablespace online without having to recover it. For example: SQL> ALTER TABLESPACE users OFFLINE NORMAL; 3. Back up the offline datafiles. For example: % cp /oracle/oradata/trgt/users01.dbf /d2/users01_'date "+%m_%d_%y"'.dbf 4. Bring the tablespace online. For example: ALTER TABLESPACE users ONLINE; Note: If you took the tablespace offline using temporary or immediate priority, then you cannot bring the tablespace online unless you perform tablespace recovery. 5. Archive the unarchived redo logs so that the redo required to recover the tablespace backup is archived. For example, enter: ALTER SYSTEM ARCHIVE LOG CURRENT;
8.3.2 Making User-Managed Backups of Online Tablespaces and Datafiles

You can back up all or only specific datafiles of an online tablespace while the database is open. The procedure differs depending on whether the online tablespace is read/write or read-only. Note: You should not back up temporary tablespaces.
8.3.3 Making User-Managed Backups of Online Read/Write Tablespaces

You must put a read/write tablespace in backup mode to make user-managed datafile backups when the tablespace is online and the database is open. The ALTER TABLESPACE ... BEGIN BACKUP statement places a tablespace in backup mode. In backup mode, the database copies whole changed data blocks into the redo stream. After you take the tablespace out of backup mode with the ALTER TABLESPACE ... END BACKUP or ALTER DATABASE END BACKUP statement, the database advances the datafile checkpoint SCN to the current database checkpoint SCN. When restoring a datafile backed up in this way, the database asks for the appropriate set of redo log files to apply if recovery be needed. The redo logs contain all changes required to recover the datafiles and make them consistent. To back up online read/write tablespaces in an open database:
Page 57 of 212
1. Before beginning a backup of a tablespace, identify all of the datafiles in the tablespace with the DBA_DATA_FILES data dictionary view. For example, assume that you want to back up the users tablespace. Enter the following: SELECT TABLESPACE_NAME, FILE_NAME FROM WHERE SYS.DBA_DATA_FILES TABLESPACE_NAME = 'USERS'; FILE_NAME -------------------/oracle/oradata/trgt/users01.dbf /oracle/oradata/trgt/users02.dbf
TABLESPACE_NAME ------------------------------USERS USERS
2. Mark the beginning of the online tablespace backup. For example, the following statement marks the start of an online backup for the tablespace users: SQL> ALTER TABLESPACE users BEGIN BACKUP; Caution: If you do not use BEGIN BACKUP to mark the beginning of an online tablespace backup and wait for this statement to complete before starting your copies of online tablespaces, then the datafile copies produced are not usable for subsequent recovery operations. Attempting to recover such a backup is risky and can return errors that result in inconsistent data. For example, the attempted recovery operation can issue a fuzzy file warning, and can lead to an inconsistent database that you cannot open. 3. Back up the online datafiles of the online tablespace with operating system commands. For example, Linux and UNIX users might enter: % cp /oracle/oradata/trgt/users01.dbf /d2/users01_'date "+%m_%d_%y"'.dbf % cp /oracle/oradata/trgt/users02.dbf /d2/users02_'date "+%m_%d_%y"'.dbf 4. After backing up the datafiles of the online tablespace, run the SQL statement ALTER TABLESPACE with the END BACKUP option. For example, the following statement ends the online backup of the tablespace users: SQL> ALTER TABLESPACE users END BACKUP; 5. Archive the unarchived redo logs so that the redo required to recover the tablespace backup is archived. For example, enter: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; Caution: If you fail to take the tablespace out of backup mode, then Oracle Database continues to write copies of data blocks in this tablespace to the online redo logs, causing performance problems. Also, you receive an ORA01149 error if you try to shut down the database with the tablespaces still in backup mode.
8.3.4 Making Multiple User-Managed Backups of Online Read/Write Tablespaces

When backing up several online tablespaces, you can back them up either serially or in parallel. Use either of the following procedures depending on your needs. Backing up Online Tablespaces in Parallel You can simultaneously create datafile copies of multiple tablespaces requiring backups in backup mode. Note, however, that by putting all tablespaces in online mode at once, you can generate large redo logs if there is heavy update activity on the affected tablespaces, because the redo must contain a copy of each changed data block in each changed datafile. Be sure to consider the size of the likely redo before using the procedure outlined here.To back up online tablespaces in parallel: 1. Prepare all online tablespaces for backup by issuing all necessary ALTER TABLESPACE statements at once. For example, put tablespaces users, tools, and indx in backup mode as follows: SQL> ALTER TABLESPACE users BEGIN BACKUP; SQL> ALTER TABLESPACE tools BEGIN BACKUP; SQL> ALTER TABLESPACE indx BEGIN BACKUP; If you are backing up all tablespaces, you might want to use this command: SQL> ALTER DATABASE BEGIN BACKUP; 2. Back up all files of the online tablespaces. For example, a Linux or UNIX user might back up datafiles with the *.dbf suffix as follows:
User Managed Database Backups % cp $ORACLE_HOME/oradata/trgt/*.dbf /disk2/backup/ 3. Take the tablespaces out of backup mode as in the following example: SQL> ALTER TABLESPACE users END BACKUP; SQL> ALTER TABLESPACE tools END BACKUP; SQL> ALTER TABLESPACE indx END BACKUP;
Page 58 of 212
Again, it you are handling all datafiles at once you can use the ALTER DATABASE command instead of ALTER TABLESPACE: SQL> ALTER DATABASE END BACKUP; 4. Archive the online redo logs so that the redo required to recover the tablespace backups will be available for later media recovery. For example, enter: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT; Backing up Online Tablespaces Serially You can place all tablespaces requiring online backups in backup mode one at a time. Oracle recommends the serial backup option because it minimizes the time between ALTER TABLESPACE ... BEGIN/END BACKUP statements. During online backups, more redo information is generated for the tablespace because whole data blocks are copied into the redo log. To back up online tablespaces serially: 1. Prepare a tablespace for online backup. For example, to put tablespace users in backup mode enter the following: SQL> ALTER TABLESPACE users BEGIN BACKUP; In this case you probably do not want to use ALTER DATABASE BEGIN BACKUP to put all tablespaces in backup mode simultaneously, because of the unnecessary volume of redo log information generated for tablespaces in online mode. 2. Back up the datafiles in the tablespace. For example, enter: % cp /oracle/oradata/trgt/users01.dbf /d2/users01_'date "+%m_%d_%y"'.dbf 3. Take the tablespace out of backup mode. For example, enter: SQL> ALTER TABLESPACE users END BACKUP; 4. Repeat this procedure for each remaining tablespace. 5. Archive the unarchived redo logs so that the redo required to recover the tablespace backups is archived. For example, enter: SQL> ALTER SYSTEM ARCHIVE LOG CURRENT;
8.3.6 Ending a Backup after an Instance Failure or SHUTDOWN ABORT

The following situations can cause a tablespace backup to fail and be incomplete: The backup completed, but you did not run the ALTER TABLESPACE ... END BACKUP statement. An instance failure or SHUTDOWN ABORT interrupted the backup. Whenever crash recovery is required, if a datafile is in backup mode when an attempt is made to open it, then the database will not open the database until either a recovery command is issued, or the datafile is taken out of backup mode. For example, the database may display a message such as the following at startup: ORA-01113: file 12 needs media recovery ORA-01110: data file 12: '/oracle/dbs/tbs_41.f' If the database indicates that the datafiles for multiple tablespaces require media recovery because you forgot to end the online backups for these tablespaces, then so long as the database is mounted, running the ALTER DATABASE END BACKUP statement takes all the datafiles out of backup mode simultaneously. In high availability situations, and in situations when no DBA is monitoring the database, the requirement for user intervention is intolerable. Hence, you can write a crash recovery script that does the following: 1. Mounts the database
Page 59 of 212
2. Runs the ALTER DATABASE END BACKUP statement 3. Runs ALTER DATABASE OPEN, allowing the system to come up automatically An automated crash recovery script containing ALTER DATABASE END BACKUP is especially useful in the following situations: All nodes in an Oracle Real Application Clusters (Oracle RAC) configuration fail. One node fails in a cold failover cluster (that is, a cluster that is not a RAC configuration in which the secondary node must mount and recover the database when the first node fails). Alternatively, you can take the following manual measures after the system fails with tablespaces in backup mode: Recover the database and avoid issuing END BACKUP statements altogether. Mount the database, then run ALTER TABLESPACE ... END BACKUP for each tablespace still in backup mode. Ending Backup Mode with the ALTER DATABASE END BACKUP Statement you can run the ALTER DATABASE END BACKUP statement when you have multiple tablespaces still in backup mode. The primary purpose of this command is to allow a crash recovery script to restart a failed system without DBA intervention. You can also perform the following procedure manually. To take tablespaces out of backup mode simultaneously: 1. Mount but do not open the database. For example, enter: SQL> STARTUP MOUNT 2. If performing this procedure manually (that is, not as part of a crash recovery script), query the V$BACKUP view to list the datafiles of the tablespaces that were being backed up before the database was restarted: SQL> SELECT * FROM V$BACKUP WHERE STATUS = 'ACTIVE'; FILE# STATUS CHANGE# TIME
---------- ------------------ ---------- --------12 ACTIVE 13 ACTIVE 20 ACTIVE 3 rows selected. 3. Issue the ALTER DATABASE END BACKUP statement to take all datafiles currently in backup mode out of backup mode. For example, enter: SQL> ALTER DATABASE END BACKUP; You can use this statement only when the database is mounted but not open. If the database is open, then use ALTER TABLESPACE ... END BACKUP or ALTER DATABASE DATAFILE ... END BACKUP for each affected tablespace or datafile. Caution: Do not use ALTER DATABASE END BACKUP if you have restored any of the affected files from a backup. Ending Backup Mode with the SQL*Plus RECOVER Command: The ALTER DATABASE END BACKUP statement is not the only way to respond to a failed online backup: you can also run the SQL*Plus RECOVER command. This method is useful when you are not sure whether someone has restored a backup, because if someone has indeed restored a backup, then the RECOVER command brings the backup up to date. Only run the ALTER DATABASE END BACKUP or ALTER TABLESPACE ... END BACKUP statement if you are sure that the files are current. Note: The RECOVER command method is slow because the database must scan redo generated from the beginning of the online backup. To take tablespaces out of backup mode with the RECOVER command:
20863 25-NOV-02 20863 25-NOV-02 20863 25-NOV-02
User Managed Database Backups 1. Mount the database. For example, enter: SQL> STARTUP MOUNT 2. Recover the database as normal. For example, enter: SQL> RECOVER DATABASE 3. Use the V$BACKUP view to confirm that there are no active datafiles: SQL> SELECT * FROM V$BACKUP WHERE STATUS = 'ACTIVE'; FILE# STATUS CHANGE# TIME
Page 60 of 212
---------- ------------------ ---------- --------0 rows selected.
8.3.7 Making User-Managed Backups of Read-Only Tablespaces

When backing up an online read-only tablespace, you can simply back up the online datafiles. You do not have to place the tablespace in backup mode because the database is not permitting changes to the datafiles. If the set of read-only tablespaces is self-contained, then in addition to backing up the tablespaces with operating system commands, you can also export the tablespace metadata with the transportable tablespace functionality. In the event of a media error or a user error (such as accidentally dropping a table in the read-only tablespace), you can transport the tablespace back into the database. To back up online read-only tablespaces in an open database: 1. Query the DBA_TABLESPACES view to determine which tablespaces are read-only. For example, run this query: SELECT TABLESPACE_NAME, STATUS FROM DBA_TABLESPACES WHERE STATUS = 'READ ONLY'; 2. Before beginning a backup of a read-only tablespace, identify all of the tablespace's datafiles by querying the DBA_DATA_FILES data dictionary view. For example, assume that you want to back up the history tablespace: SELECT TABLESPACE_NAME, FILE_NAME FROM SYS.DBA_DATA_FILES WHERE TABLESPACE_NAME = 'HISTORY'; TABLESPACE_NAME ------------------------------HISTORY HISTORY FILE_NAME -------------------/oracle/oradata/trgt/history01.dbf /oracle/oradata/trgt/history02.dbf
3. Back up the online datafiles of the read-only tablespace with operating system commands. You do not have to take the tablespace offline or put the tablespace in backup mode because users are automatically prevented from making changes to the read-only tablespace. For example: % cp $ORACLE_HOME/oradata/trgt/history*.dbf /disk2/backup/ Note: When restoring a backup of a read-only tablespace, take the tablespace offline, restore the datafiles, and then bring the tablespace online. A backup of a read-only tablespace is still usable if the read-only tablespace is made read/write after the backup, but the restored backup will require recovery. 4. Optionally, export the metadata in the read-only tablespace. By using the transportable tablespace feature, you can quickly restore the datafiles and import the metadata in case of media failure or user error. For example, export the metadata for tablespace history as follows: % expdp DIRECTORY=dpump_dir1 DUMPFILE=hs.dmp TRANSPORT_TABLESPACES=history > LOGFILE=tts.log
8.4 Making User-Managed Backups of the Control File

Back up the control file of a database after making a structural modification to a database operating in ARCHIVELOG mode. To back up a database's control file, you must have the ALTER DATABASE system privilege.
Page 61 of 212
8.4.1 Backing up the Control File to a Binary File

The primary method for backing up the control file is to use a SQL statement to generate a binary file. A binary backup is preferable to a trace file backup because it contains additional information such a s the archived log history, offline range for read-only and offline tablespaces, and backup sets and copies (if you use RMAN). If COMPATIBLE is 10.2 or higher, binary control file backups include tempfile entries. To back up the control file after a structural change: 1. Make the desired change to the database. For example, you ma y create a new tablespace: CREATE TABLESPACE tbs_1 DATAFILE 'file_1.f' SIZE 10M; 2. Back up the database's control file, specifying a filename for the output binary file. The following example backs up a control file to /disk1/backup/cf.bak: ALTER DATABASE BACKUP CONTROLFILE TO '/disk1/backup/cf.bak' REUSE; Specify REUSE to make the new control file overwrite one that currently exists.
8.4.2 Backing up the Control File to a Trace File

You can back up the control file to a text file that contains a CREATE CONTROLFILE statement. You can edit the trace file to create a script that creates a new control file based on the control file that was current when you created the trace file. If you specify neither the RESETLOGS nor NORESETLOGS option in the SQL statement, then the resulting trace file contains versions of the control file for both RESETLOGS and NORESETLOGS options. Tempfile entries are included in the output using ALTER TABLESPACE ... ADD TEMPFILE statements. To avoid recovering offline normal or read-only tablespaces, edit them out of the CREATE CONTROLFILE statement. When you open the database with the re-created control file, the database marks these omitted files as MISSING. You can run an ALTER DATABASE RENAME FILE statement to rename them to their original filenames. To back up the control file to a trace file: 1. Mount or open the database. 2. Execute the following SQL statement: ALTER DATABASE BACKUP CONTROLFILE TO TRACE; The trace files are stored in a subdirectory determined by the DIAGNOSTIC_DEST initialization parameter. To locate the directory for trace files, query the name and value columns of the V$DIAG_INFO dynamic performance view.
8.5 Making User-Managed Backups of Archived Redo Logs

To save disk space in your primary archiving location, you may want to back up archived logs to tape or to an alternative disk location. If you archive to multiple locations, then only back up one copy of each log sequence number. To back up archived redo logs: 1. To determine which archived redo log files that the database has generated, query V$ARCHIVED_LOG. For example, run the following query: SELECT THREAD#,SEQUENCE#,NAME FROM V$ARCHIVED_LOG; 2. Back up one copy of each log sequence number by using an operating system utility. This example backs up all logs in the primary archiving location to a disk devoted to log backups: % cp $ORACLE_HOME/oracle/trgt/arch/* /disk2/backup/arch
Recovery Manager(RMAN)
Page 62 of 212
9. Recovery Manager (RMAN)

9.1 Overview of the RMAN Environment
Recovery Manager (RMAN) is an Oracle Database client that performs backup and recovery tasks on your databases and automates administration of your backup strategies. It greatly simplifies backing up, restoring, and recovering database files. The RMAN environment consists of the utilities and databases that play a role in backing up your data. At a minimum, the environment for RMAN must include the following components: A target database An Oracle database to which RMAN is connected with the TARGET keyword. A target database is a database on which RMAN is performing backup and recovery operations. RMAN always maintains metadata about its operations on a database in the control file of the database. The RMAN metadata is known as the RMAN repository. The RMAN client An Oracle Database executable that interprets commands, directs server sessions to execute those commands, and records its activity in the target database control file. The RMAN executable is automatically installed with the database and is typically located in the same directory as the other database executables. For example, the RMAN client on Linux is located in $ORACLE_HOME/bin. Some environments use the following optional components: A flash recovery area A disk location in which the database can store and manage files related to backup and recovery. You set the flash recovery area location and size with the DB_RECOVERY_FILE_DEST and DB_RECOVERY_FILE_DEST_SIZE initialization parameters. A media manager An application required for RMAN to interface with sequential media devices such as tape libraries. A media manager controls these devices during backup and recovery, managing the loading, labeling, and unloading of media. Media management devices are sometimes called SBT (system backup to tape) devices. A recovery catalog A separate database schema used to record RMAN activity against one or more target databases. A recovery catalog preserves RMAN repository metadata if the control file is lost, making it much easier to restore and recover following the loss of the control file. The database may overwrite older records in the control file, but RMAN maintains records forever in the catalog unless deleted by the user.
9.2 Starting RMAN and Connecting to Database

The RMAN client is started by issuing the rman command at the command prompt of your operating system. After being started, RMAN displays a prompt for your commands as shown in the following example: % rman RMAN> RMAN connections to a database are specified and authenticated in the same way as SQL*Plus connections to a database. The only difference is that RMAN connections to a target or auxiliary database require the SYSDBA privilege. The AS SYSDBA keywords are implied and cannot be explicitly specified. Caution: Good security practice requires that passwords should not be entered in plain text on the command line. You should enter passwords in RMAN only when requested by an RMAN prompt.
Page 63 of 212
You can connect to a database with command-line options or by using the CONNECT TARGET command. The following example starts RMAN and then connects to a target database through Oracle Net (note that AS SYSDBA is not specified because it is implied). RMAN prompts for a password. % rman RMAN> CONNECT TARGET SYS@prod target database Password: password connected to target database: PROD (DBID=39525561) The following variation starts RMAN and then connects to a target database by using operating system authentication: % rman RMAN> CONNECT TARGET / connected to target database: PROD (DBID=39525561) To quit the RMAN client, enter EXIT at the RMAN prompt: RMAN> EXIT
Syntax of Common RMAN Command-line Options

RMAN [ TARGET connectStringSpec | { CATALOG connectStringSpec } | LOG ['] filename ['] [ APPEND ] . . . ]...
connectStringSpec::= ['] [userid] [/ [password]] [@net_service_name] ['] The following example appends the output from an RMAN session to a text file at /tmp/msglog.log % rman TARGET / LOG /tmp/msglog.log APPEND
9.3 Showing the Default RMAN Configuration

The RMAN backup and recovery environment is preconfigured for each target database. The configuration is persistent and applies to all subsequent operations on this target database, even if you exit and restart RMAN.RMAN configured settings can specify backup devices, configure a connection to a backup device (known as a channel), policies affecting backup strategy, and others. The default configuration is adequate for most purposes. To show the current configuration for a database: 1. Start RMAN and connect to a target database. 2. Run the SHOW ALL command. For example, enter the command at the RMAN prompt as follows: RMAN> SHOW ALL; The output lists the CONFIGURE commands to re-create this configuration.
Page 64 of 212
9.4 Backing up a Database

Use the BACKUP command to back up files. RMAN backs up data to the configured default device for the type of backup requested. By default, RMAN creates backups on disk. If a flash recovery area is enabled, and if you do not specify the FORMAT parameter, then RMAN creates backups in the recovery area and automatically gives them unique names. By default, RMAN creates backup sets rather than image copies. A backup set consists of one or more backup pieces, which physical files are written in a format that only RMAN can access. A multiplexed backup set contains the blocks from multiple input files. RMAN can write backup sets to disk or tape. If you specify BACKUP AS COPY, then RMAN copies each file as an image copy, which is a bit-for-bit copy of a database file created on disk. Image copies are identical to copies created with operating system commands like cp on Linux or COPY on Windows, but are recorded in the RMAN repository and so are usable by RMAN. You can use RMAN to make image copies while the database is open.
9.4.1 Backing up a Database in ARCHIVELOG Mode

If a database runs in ARCHIVELOG mode, then you can back up the database while it is open. The backup is called an inconsistent backup because redo is required during recovery to bring the database to a consistent state. As long as you have the archived redo logs needed to recover the backup, open database backups are as effective a means of data protection as consistent backups. To back up the database and archived redo logs while the database is open: 1. Start RMAN and connect to a target database. 2. Run the BACKUP DATABASE command. For example, enter the following command a t the RMAN prompt to back up the database and all archived redo log files to the default backup device: RMAN> BACKUP DATABASE PLUS ARCHIVELOG;
9.4.2 Backing up a Database in NOARCHIVELOG Mode

If a database runs in NOARCHIVELOG mode, then the only valid database backup is a consistent backup. For the backup to be consistent, the database must be mounted after a consistent shutdown. No recovery is required after restoring the backup. To make a consistent database backup: 1. Start RMAN and connect to a target database. 2. Shut down the database consistently and then mount it. For example, enter the following commands to guarantee that the database is in a consistent state for a backup: RMAN> SHUTDOWN IMMEDIATE RMAN> STARTUP FORCE DBA; RMAN> SHUTDOWN IMMEDIATE; RMAN> STARTUP MOUNT; 3. Run the BACKUP DATABASE command. For example, enter the following command a t the RMAN prompt to back up the database to the default backup device: RMAN> BACKUP DATABASE; The following variation of the command creates image copy backups of all datafiles in the database: RMAN> BACKUP AS COPY DATABASE; 4. Open the database and resume normal operations. The following command opens the database: RMAN> ALTER DATABASE OPEN;
9.4.3 Typical Backup Options

The BACKUP command includes a host of options, parameters, and clauses that control backup output. The following table lists some typical backup options.
Page 65 of 212
If you specify BACKUP INCREMENTAL, then RMAN creates an incremental backup of a database. Incremental backups capture block-level changes to a database made after a previous incremental backup. Incremental backups are generally smaller and faster to make than full database backups. Recovery with incremental backups is faster than using redo logs alone. The starting point for an incremental backup strategy is a level 0 incremental backup, which backs up all blocks in the database. An incremental backup at level 0 is identical in content to a full backup, but unlike a full backup the level 0 backup is considered a part of the incremental backup strategy. A level 1 incremental backup contains only blocks changed after a previous incremental backup. If no level 0 backup exists in either the current or parent database incarnation when you run a level 1 backup, then RMAN makes a level 0 backup automatically. Note: You cannot make incremental backups when a NOARCHIVELOG database is open, although you can make incremental backups when the database is mounted after a consistent shutdown. A level 1 backup can be a cumulative incremental backup, which includes all blocks changed since the most recent level 0 backup, or a differential incremental backup, which includes only blocks changed since the most recent incremental backup. Incremental backups are differential by default. When restoring incremental backups, RMAN uses the level 0 backup as the starting point, then updates changed blocks based on level 1 backups where possible to avoid reapplying changes from redo one at a time. Recovering with incremental backups requires no additional effort on your part. If incremental backups are available, then RMAN uses them during recovery. To make incremental backups of the database: 1. Start RMAN and connect to a target database. 2. Run the BACKUP INCREMENTAL command. The following example creates a level 0 incremental backup to serve as a base for an incremental backup strategy: BACKUP INCREMENTAL LEVEL 0 DATABASE; The following example creates a level 1 cumulative incremental backup: BACKUP INCREMENTAL LEVEL 1 CUMULATIVE DATABASE; The following example creates a level 1 differential incremental backup: BACKUP INCREMENTAL LEVEL 1 DATABASE;
9.4.4 Making Incrementally Updated Backups

The RMAN incrementally updated backup feature is an efficient incremental backup routine. Changes from level 1 backups roll forward an image copy level 0 incremental backup, so that it includes all changes as of the SCN at which the level 1 incremental backup was created. Recovery of the updated level 0 incremental backup is faster because all changes from the level 1 incremental backup have already been applied. The BACKUP FOR RECOVER OF COPY command specifies that an incremental backup should contain all changes since the SCN of a specified datafile copy (level 0 incremental backup) of your database. The following table explains which options
Page 66 of 212
to use with FOR RECOVER OF COPY to implement an incrementally updated backup strategy. To implement an incrementally updated backup strategy: 1. Start RMAN and connect to a target database. 2. Run the RECOVER COPY and BACKUP INCREMENTAL commands. The following script, run on a regular basis, is all that is required to implement a strategy based on incrementally updated backups. RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; You can use the VALIDATE command to confirm that all database files exist, are in their correct location, and are free of physical corruption. The CHECK LOGICAL option also checks for logical block corruption. To validate database files: 1. Start RMAN and connect to a target database. 2. Run the VALIDATE command for the desired files. For example, enter the following commands to validate all database files and archived redo log files for physical and logical corruption: BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL; You can also use the VALIDATE command to individual data blocks, as shown in the following example: VALIDATE DATAFILE 4 BLOCK 10 TO 13; You can also validate backup sets, as shown in the following example: VALIDATE BACKUPSET 3; You specify backup sets by primary key, which is shown in the output of the LIST BACKUP command.
9.5 Scripting RMAN Operations

RMAN supports the use of command files to manage recurring tasks such as weekly backups. A command file is a client-side text file containing RMAN commands, exactly as you enter them at the RMAN prompt. You can use any file extension. The RUN command provides a degree of flow-of-control in your scripts. To create and run a command file: 1. Use a text editor to create a command file. For example, create a command file with the following contents: # my_command_file.txt CONNECT TARGET / BACKUP DATABASE PLUS ARCHIVELOG; LIST BACKUP; EXIT; 2. Start RMAN and then execute the contents of a command file by running the @ command at the RMAN prompt: % rman RMAN> @/my_dir/my_command_file.txt # runs specified command file You can also launch RMAN with a command file to run, as shown here: % rman @/my_dir/my_command_file.txt
9.6 Reporting on RMAN Operations

The RMAN LIST and REPORT commands generate reports on backup activities based on the RMAN repository. Use the SHOW ALL command to display the current RMAN configuration.
Page 67 of 212
9.6.1 Listing Backups

Run the LIST BACKUP and LIST COPY commands to display information about backups and datafile copies listed in the repository. For backups, you can control the format of LIST output with the options in the following tables. Table - LIST Options for Backups
To list backups and copies: 1. Start RMAN and connect to a target database. 2. Run the LIST command at the RMAN prompt. You can display specific objects, as in the following examples: LIST BACKUP OF DATABASE; LIST COPY OF DATAFILE 1, 2; LIST BACKUP OF ARCHIVELOG FROM SEQUENCE 10; LIST BACKUPSET OF DATAFILE 1;
9.6.2 Reporting on Database Files and Backups

The REPORT command performs more complex analysis than LIST. Some of the main options are shown in the following table. Table - REPORT Options
To generate reports of database files and backups: 1. Start RMAN and connect to a target database. 2. Run the REPORT command at the RMAN prompt. The following example reports backups that are obsolete according to the currently configured backup retention policy: REPORT OBSOLETE; The following example reports the datafiles and tempfiles in the database:
Recovery Manager(RMAN) REPORT SCHEMA;
Page 68 of 212
9.7 Maintaining RMAN Backups

RMAN repository metadata is always stored in the control file of the target database. The RMAN maintenance commands use this metadata when managing backups.
9.7.1 Crosschecking Backups

The CROSSCHECK command synchronizes the logical records of RMAN backups and copies with the files on storage media. If a backup is on disk, then CROSSCHECK determines whether the header of the file is valid. If a backup is on tape, then RMAN queries the RMAN repository for the names and locations of the backup pieces. It is a good idea to crosscheck backups and copies before deleting them. To crosscheck all backups and copies on disk: 1. Start RMAN and connect to a target database. 2. Run the CROSSCHECK command, as shown in the following example: CROSSCHECK BACKUP; CROSSCHECK COPY;
9.7.2 Deleting Obsolete Backups

The DELETE command removes RMAN backups and copies from disk and tape, updates the status of the files to DELETED in the control file repository, and removes the records from the recovery catalog (if you use a catalog). If you run RMAN interactively, and if you do not specify the NOPROMPT option, then DELETE displays a list of files and prompts for confirmation before deleting any file in the list. The DELETE OBSOLETE command is particular useful because RMAN deletes backups and datafile copies recorded in the RMAN repository that are obsolete, which is, no longer needed. You can use options on the DELETE command to specify what is obsolete or use the configured backup retention policy. To delete obsolete backups and copies: 1. Start RMAN and connect to a target database. 2. Run the DELETE OBSOLETE command, as shown in the following example: DELETE OBSOLETE;
9.8 Diagnosing and Repairing Failures with Data Recovery Advisor

The simplest way to diagnose and repair database problems is to use the Data Recovery Advisor. This Oracle Database tool provides an infrastructure for diagnosing persistent data failures, presenting repair options to the user, and automatically executing repairs.
9.8.1 Listing Failures and Determining Repair Options

A failure is a persistent data corruption detected by the Health Monitor. Examples include physical and logical data block corruptions and missing datafiles. Each failure has a failure priority and failure status. The priority can be CRITICAL, HIGH, or LOW. The status can be OPEN or CLOSED. You can run the LIST FAILURE command to show a ll known failures. If failures exist, then run the ADVISE FAILURE command in the same session to determine manual and automated repair options. The following example illustrates these two commands (sample output included). Example - LIST FAILURE and ADVISE FAILURE RMAN> LIST FAILURE; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------142 missing

HIGH
OPEN
23-APR-07
One or more non-system datafiles are
Recovery Manager(RMAN) 101 HIGH OPEN 23-APR-07 Datafile 1:
Page 69 of 212
'/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
RMAN> ADVISE FAILURE; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------142 HIGH OPEN 23-APR-07 One or more non-system datafiles are missing 101 HIGH OPEN 23-APR-07 Datafile 1:
analyzing automatic repair options; this may take some time using channel ORA_DISK_1 analyzing automatic repair options complete
Mandatory Manual Actions ======================== no manual actions available Optional Manual Actions ======================= 1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it Automated Repair Options ======================== Option Repair Description ------ -----------------1 Restore and recover datafile 28; Perform block media recovery of block 56416 in file 1 Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm The ADVISE FAILURE output shows both manual and automated repair options. First try to fix the problem manually. If you cannot fix the problem manually, then review the automated repair section. An automated repair option describes a server-managed repair for one or more failures. Repairs are consolidated when possible so that a single repair can fix multiple failures. The repair option indicates which repair will be performed and whether data will be lost by performing the repair. In Example, the output indicates the filename of a repair script containing RMAN commands. If you do not want to use Data Recovery Advisor to repair the failure automatically, then you can use the script as the basis of your own recovery strategy.
9.8.2 Repairing Failures

After running LIST FAILURE and ADVISE FAILURE in an RMAN session, you can run REPAIR FAILURE to execute a repair option. If you execute REPAIR FAILURE with no other command options, then RMAN uses the first repair option of the most recent ADVISE FAILURE command in the current session. Alternatively, specify the repair option number obtained from the most recent ADVISE FAILURE command.
Recovery Manager(RMAN) Example - REPAIR FAILURE REPAIR FAILURE;
Page 70 of 212
By default, REPAIR FAILURE prompts for confirmation before it begins executing. After executing a repair, Data Recovery Advisor reevaluates all existing failures on the possibility that they may also have been fixed. Data Recovery Advisor always verifies that failures are still relevant and automatically closes fixed failures. If a repair fails to complete because of an error, then the error triggers a new assessment and re-evaluation of existing failures and repairs.
9.8.3 Rewinding a Database with Flashback Database

You can use the Oracle Flashback Database to rewind the whole database to a past time. Unlike media recovery, you do not need to restore datafiles to return the database to a past state. To use the RMAN FLASHBACK DATABASE command, your database must have been previously configured to generated flashback logs. Flashback Database works by rewinding changes to the datafiles that exist at the moment that you run the command. You cannot use the command to repair media failures or missing datafiles. The database must be mounted when you issue FLASHBACK DATABASE. Note that if you have previously created a restore point, then you can flash back to this restore point if it falls within the flashback database window. To rewind a database with Flashback Database: 1. Start RMAN and connect to a target database. 2. Ensure that the database is in a mounted state. The following commands shut down and then mount the database: SHUTDOWN IMMEDIATE; STARTUP MOUNT; 3. Run the FLASHBACK DATABASE command. The following examples illustrate different forms of the command: FLASHBACK DATABASE TO SCN 861150; FLASHBACK DATABASE TO RESTORE POINT BEFORE_CHANGES; FLASHBACK DATABASE TO TIME "TO_DATE('06/20/07','MM/DD/YY')"; 4. After performing the Flashback Database, open the database read-only in SQL*Plus and run some queries to verify the database contents. Open the database read-only as follows: SQL "ALTER DATABASE OPEN READ ONLY"; 5. If satisfied with the results, then issue the following sequence of commands to shut down and then open the database: SHUTDOWN IMMEDIATE; STARTUP MOUNT; ALTER DATABASE OPEN RESETLOGS;
9.9 Restoring and Recovering Database Files

Use the RESTORE and RECOVER commands for RMAN restore and recovery of physical database files. Restoring datafiles is retrieving them from backups as needed for a recovery operation. Media recovery is the application of changes from redologs and incremental backups to a restored datafile to bring the datafile forward to a desired SCN or point in time.
9.9.1 Preparing to Restore and Recover Database Files

If you need to recover the database because a media failure damages database files, then you should first ensure that you have the necessary backups. You can use the RESTORE ... PREVIEW command to report, but not restore, the backups that RMAN could use to restore to the specified time. RMAN queries the metadata and does
Page 71 of 212
not actually read the backup files. The database can be open when you run this command. To preview a database restore and recovery: 1. Start RMAN and connect to the target database. 2. Optionally, list the current tablespaces and datafiles, as shown in the following command: RMAN> REPORT SCHEMA; 3. Run the RESTORE DATABASE command with the PREVIEW option. The following command specifies SUMMARY so that the backup metadata is not displayed in verbose mode (sample output included): RMAN> RESTORE DATABASE PREVIEW SUMMARY; Starting restore at 21-MAY-07 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=80 device type=DISK List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- --11 B F A DISK 18-MAY-07 1 2 NO
TAG20070518T181114 13 B F A DISK 18-MAY-07 1 2 NO
TAG20070518T181114 using channel ORA_DISK_1
List of Archived Log Copies for database with db_unique_name PROD =====================================================================
Key
Thrd Seq
S Low Time
------- ---- ------- - --------47 1 18 A 18-MAY-07
Name: /disk1/oracle/dbs/db1r_60ffa882_1_18_0622902157.arc
Media recovery start SCN is 586534 Recovery must be done beyond SCN 587194 to clear datafile fuzziness validation succeeded for backup piece Finished restore at 21-MAY-07
9.9.2 Recovering the Whole Database

Use the RESTORE DATABASE and RECOVER DATABASE commands to recover the whole database. You must have previously made backups of all needed files. This scenario assumes that you can restore all datafiles to their original locations. If the original locations are inaccessible, then use the SET NEWNAME command as described in "Restoring Datafiles to a Non-default Location_. To recover the whole database: 1. Prepare for recovery as explained in "Preparing to Restore and Recover Database Files. 2. Place the database in a mounted state. The following example terminates the database instance (if it is started) and mounts the database: RMAN> STARTUP FORCE MOUNT; 3. Restore the database. The following example uses the preconfigured disk channel to restore the database: RMAN> RESTORE DATABASE;
Recovery Manager(RMAN) 4. Recover the database, as shown in the following example: RMAN> RECOVER DATABASE; 5. Open the database, as shown in the following example: RMAN> ALTER DATABASE OPEN;
Page 72 of 212
9.9.3 Recovering Tablespaces

Use the RESTORE TABLESPACE and RECOVER TABLESPACE commands on individual tablespaces when the database is open. In this case, must take the tablespace that needs recovery offline, restore and then recover the tablespace, and bring the recovered tablespace online. If you cannot restore a datafile to a new location, then use the RMAN SET NEWNAME command within a RUN command to specify the new filename. Afterward, use a SWITCH DATAFILE ALL command, which is equivalent to using the SQL statement ALTER DATABASE RENAME FILE, to update the control file to reflect the new names for all datafiles for which a SET NEWNAME has been issued in the RUN command. Unlike in user-managed media recovery, you should not place an online tablespace in backup mode. Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. To recover an individual tablespace when the database is open: 1. Prepare for recovery as explained in Preparing to restore and Recover Database Files_. 2. Take the tablespace to be recovering offline: The following example takes the users tablespace offline: RMAN> SQL 'ALTER TABLESPACE users OFFLINE'; 3. Restore and recover the tablespace. The following RUN command, which you execute at the RMAN prompt, sets a new name for the datafile in the users tablespace: RUN { SET NEWNAME FOR DATAFILE '/disk1/oradata/prod/users01.dbf' TO '/disk2/users01.dbf'; RESTORE TABLESPACE users; SWITCH DATAFILE ALL; # update control file with new filenames
RECOVER TABLESPACE users; } 4. Bring the tablespace online, as shown in the following example: RMAN> SQL 'ALTER TABLESPACE users ONLINE'; You can also use RESTORE DATAFILE and RECOVER DATAFILE for recovery at the datafile level.
9.9.4 Recovering Individual Data Blocks

RMAN can recover individual corrupted datafile blocks. When RMAN performs a complete scan of a file for a backup, any corrupted blocks are listed in V$DATABASE_BLOCK_CORRUPTION. Corruption is usually reported in alert logs, trace files, or results of SQL queries. To recover data blocks: 1. Obtain the block numbers of the corrupted blocks if you do not already have this information. The easiest way to locate trace files and the alert log is to connect SQL*Plus to the target database and execute the following query: SQL> SELECT NAME, VALUE 2 FROM V$DIAG_INFO; 2. Start RMAN and connect to the target database. 3. Run the RECOVER command to repair the blocks. The following RMAN command recovers all corrupted blocks: RMAN> RECOVER CORRUPTION LIST; You can also recover individual blocks, as shown in the following example: RMAN> RECOVER DATAFILE 1 BLOCK 233, 235 DATAFILE 2 BLOCK 100 TO 200;
RMAN - Architecture
Page 73 of 212
10. Recovery Manager Architecture

10.1 About the RMAN Environment
The Recovery Manager environment consists of the various applications and databases that play a role in a backup and recovery strategy. Table lists some of the components in a typical RMAN environment.
The only required components in an RMAN environment are a target database and RMAN client, but most realworld configurations are more complicated. For example, you could use an RMAN client connecting to multiple media managers and multiple target databases and auxiliary databases, all accessed through Enterprise Manager.
RMAN - Architecture
Page 74 of 212
Figure illustrates components in a possible RMAN environment. The graphic shows that the primary database, standby database, and recovery catalog databases all reside on different computers. The primary and standby database hosts use a locally attached tape drive. The RMAN client and Enterprise Manager Console run on a separate computer. Figure - Sample RMAN Environment
10.2 RMAN Command-Line Client

Use the RMAN command-line client to enter commands that you can use to manage all aspects of backup and recovery operations. RMAN uses a command language interpreter that can execute commands in interactive or batch mode. Even when you use the backup and recovery features in Enterprise Manager that are built on top of RMAN, an RMAN client executes behind the scenes.
10.3 RMAN Channels

The RMAN client directs database server sessions to perform all backup and recovery tasks. What constitutes a session depends on the operating system. For example, on Linux, a server session corresponds to a server process, whereas on Windows it corresponds to a thread within the database service. The RMAN client itself does not perform backup, restore, or recovery operations. When you connect the RMAN client to a target database, RMAN allocates server sessions on the target instance and directs them to perform the operations. An RMAN channel represents one stream of data to a device, and corresponds to one database server session. The channel reads data into memory, processes it, and writes it to the output device.
RMAN - Architecture
Page 75 of 212
Most RMAN commands are executed by channels, which must be either configured to persist across RMAN sessions, or manually allocated in each RMAN session. As illustrated in Figure, a channel establishes a connection from the RMAN client to a target or auxiliary database instance by starting a server session on the instance.
10.4 Channels and Devices

The RMAN-supported device types are disk and SBT (system backup to tape). An SBT device is controlled by a third-party media manager. Typically, SBT devices are tape libraries and tape drives. If you use a disk channel for a backup, then the channel creates the backup on disk in the file name space of the target database instance creating the backup. You can make a backup on any device that can store a datafile. RMAN does not call a media manager when making disk backups. To create backups on non-disk media, you must use media management software such as Oracle Secure Backup and allocate channels supported by this software. RMAN contacts the media manager whenever the channel type allocated is not disk. How and when the SBT channels cause the media manager to allocate resources is vendorspecific. Some media managers allocate resources when you issue the command; others do not allocate resources until you open a file for reading or writing.
10.5 Automatic and Manual Channels

You can use the CONFIGURE CHANNEL command to configure channels for use with disk or tape across RMAN sessions. This technique is known as automatic channel allocation. RMAN comes preconfigured with one DISK channel that you can use for backups to disk. When you run a command that can use automatic channels, RMAN automatically allocates the channels with the options you specified in the CONFIGURE command. For the BACKUP command, RMAN allocates only the type of channel required to back up to the specified media. For the RESTORE command and RMAN maintenance commands, RMAN allocates all necessary channels for the device types required to execute the command. RMAN determines the names for automatic channels. You also have the option of manually allocating channels. Each manually allocated channel uses a separate connection to the database. When you manually allocate a channel, you give it a user-defined name such as dev1 or ch2.The number of channels available for use with a device when you run a command determines whether RMAN will read from or write to this device in parallel while carrying out the command. In parallelism, the backup of the files is performed by more than one channel. Each channel may back up more than one file, but unless a multisection backup is performed, no file is backed up by more than one channel.
RMAN - Architecture
Page 76 of 212
10.6 RMAN Repository

The RMAN repository is the collection of metadata about the target databases that RMAN uses for backup, recovery, and maintenance. RMAN always stores its metadata in the control file. The version of this metadata in the control file is the authoritative record of RMAN backups of your database. This is one reason why protecting your control file is a important part of your backup strategy. RMAN can conduct all necessary backup and recovery operations using just the control file to store the RMAN repository information, and maintains all records necessary to meet your configured retention policy. You can also create a recovery catalog, which is a repository of RMAN metadata stored in an Oracle database schema. The control file has finite space for records of backup activities, whereas a recovery catalog can store a much longer history. You can simplify backup and recovery administration by creating a single recovery catalog that contains the RMAN metadata for all of your databases. The owner of a recovery catalog can grant or revoke restricted access to the catalog to other database users. Each restricted user has full read/write access to his own metadata, which is called a virtual private catalog. When one or more virtual private catalogs exist in a database, the database contains just one set of catalog tables. These tables are owned by the base recovery catalog owner. The owner of the base catalog controls which databases each virtual catalog user can access. Some RMAN features only function when you use a recovery catalog. For example, you can create a stored script in the recovery catalog and use this script to execute RMAN jobs. Other RMAN commands are specifically related to managing the recovery catalog and so are not available (and not needed) if RMAN is not connected to a recovery catalog. The recovery catalog is maintained solely by RMAN. A target database instance never accesses the catalog directly. RMAN propagates information about the database structure, archived redo logs, backup sets, and datafile copies into the recovery catalog from the target database control file after any operation that updates the repository, and also before certain operations.
10.7 Media Management

Oracle's Media Management Layer (MML) API lets third-party vendors build a media manager, software that works with RMAN and the vendor's hardware to allow backups to sequential media devices such as tape drives. A media manager handles loading, unloading and labeling of sequential media such as tapes. You must install media manager software to use RMAN with sequential media devices. When backing up or restoring, the RMAN client connects to a target database instance and directs the instance to send requests to its media manager. No direct communication occurs between the RMAN client and media manager.
10.8 RMAN Interaction with a Media Manager

Before performing backup or restore to a media manager, you must allocate one or more channels to handle the communication with the media manager. You can also configure default channels for use with the media manager, which will be applied for all backup and recovery tasks that use the media manager where you do not explicitly allocate channels. RMAN does not issue specific commands to load, label, or unload tapes. When backing up, RMAN gives the media manager a stream of bytes and associates a unique name with this stream. When RMAN needs to restore the backup, it asks the media manager to retrieve the byte stream. All details of how and where that stream is stored are handled entirely by the media manager. For example, the media manager labels and keeps track of the tape and names of files on each tape, and automatically loads and unloads tapes, or signals an operator to do so. Some media managers support proxy copy functionality, in which they handle the entire data movement between datafiles and the backup devices. Such products may use technologies such as high-speed connections between storage and media subsystems to reduce load on the primary database server. RMAN provides a list of files requiring backup or restore to the media manager, which in turn makes all decisions regarding how and when to move the data.
RMAN - Architecture
Page 77 of 212
10.9 Oracle Secure Backup

Oracle Secure Backup is a media manager that provides reliable and secure data protection through file system backup to tape. All major tape drives and tape libraries in SAN, Gigabit Ethernet, and SCSI environments are supported. Although Oracle Secure Backup has no specialized knowledge of database backup and recovery algorithms; it can serve as a media management layer for RMAN through the SBT interface. In this capacity, Oracle Secure Backup provides the same services for RMAN as other supported third-party SBT libraries. Oracle Secure Backup has some features, however, that are not available in other media managers.
10.10 Backup Solutions Program

The Oracle Backup Solutions Program (BSP), part of the Oracle Partner Program, is a group of media manager vendors whose products are compliant with Oracle's MML specification. Several products may be available for your platform from media management vendors. Note that Oracle does not certify media manager vendors for compatibility with RMAN. Questions about availability, version compatibility, and functionality can only be answered by the media manager vendor, not Oracle.
10.11 Flash Recovery Area

The component that creates different backup and recovery-related files have no knowledge of each other or of the size of the file systems where they store their data. With automatic disk-based backup and recovery, you can create a flash recovery area (also simply called the recovery area), which automates management of backuprelated files. A flash recovery area minimizes the need to manually manage disk space for backup-related files and balance the use of space among the different types of files. In this way, a flash recovery area simplifies the ongoing administration of your database. Oracle recommends that you enable a recovery area to simplify backup management. When you create a recovery area, you choose a location on disk and an upper bound for storage space. You also set a backup retention policy that governs how long backup files are needed for recovery. The database manages the storage used for backups, archived redo logs, and other recovery-related files for the database within this space. Files no longer needed are eligible for deletion when RMAN needs to reclaim space for new files.
10.12 RMAN in a Data Guard Environment

When using RMAN in a Data Guard environment, a recovery catalog is required. The recovery catalog can store the metadata for all primary and standby databases. A database in a Data Guard environment is uniquely identified by means of the DB_UNIQUE_NAME parameter in the initialization parameter file. The DB_UNIQUE_NAME must be unique across all the databases with the same DBID for RMAN to work correctly in a Data Guard environment.
10.12.1 RMAN Configuration in a Data Guard Environment

To simplify ongoing use of RMAN for backup and recovery, you can set a number of persistent configuration settings for each primary and physical standby database in a Data Guard environment. These settings control many aspects of RMAN behavior. For example, you can configure the backup retention policy, default destinations for backups to tape or disk, default backup device type, and so on. You can use the CONFIGURE command with the FOR DB_UNIQUE_NAME clause to create a persistent configuration for a database in a Data Guard environment without connecting to the standby database or primary database as TARGET. For example, you connect RMAN to the recovery catalog, run the SET DBID command, and then can create a configuration for a physical standby database before its creation so that the RMAN configuration applies when the database is created. RMAN updates the control file of the database when connected to it as TARGET during a recovery catalog resynchronization. If you use FOR DB_UNIQUE_NAME for a database without
RMAN - Architecture
Page 78 of 212
being connected as TARGET to this database, however, then RMAN changes configurations in the recovery catalog only.
10.12.2 RMAN File Management in a Data Guard Environment

RMAN uses a recovery catalog to track filenames for all database files in a Data Guard environment. The catalog also records where the online redo log files, standby redo log files, tempfiles, archived redo log files, backup sets, and image copies are created.
10.12.3 Interchangeability of Backups in a Data Guard Environment

RMAN commands use the recovery catalog metadata to behave transparently across different physical databases in the Data Guard environment. For example, you can back up a tablespace on a physical standby database and restore and recover it on the primary database. Similarly, you can back up a tablespace on a primary database and restore and recover it on a physical standby database. Note: Backups of logical standby databases are not usable at the primary database. Backups of standby control files and non-standby control files are interchangeable. For example, you can restore a standby control file on a primary database and a primary control file on a physical standby database. This interchangeability means that you can offload control file backups to one database in a Data Guard environment. RMAN automatically updates the filenames for database files during restore and recovery at the databases.
10.12.4 Association of Backups in a Data Guard Environment

The recovery catalog tracks the files in the Data Guard environment by associating every database file or backup file with a DB_UNIQUE_NAME. The database that creates a file is associated with the file. For example, if RMAN backs up the database with the unique name of standby1, then standby1 is associated with this backup. A backup remains associated with the database that created in unless you use the CHANGE ... RESET DB_UNIQUE_NAME to associate the backup with a different database.
10.12.5 Accessibility of Backups in a Data Guard Environment

The accessibility of a backup is different from its association. In a Data Guard environment, the recovery catalog considers disk backups as accessible only to the database with which it is associated, whereas tape backups created on one database are accessible to all databases. If a backup file is not associated with any database, then the row describing it in the recovery catalog view shows null for the SITE_KEY column. By default, RMAN associates files whose SITE_KEY is null with the database to which it is connected as TARGET. RMAN commands such as BACKUP, RESTORE, and CROSSCHECK work on any accessible backup. For example, for a RECOVER COPY operation, RMAN considers only image copies that are associated with the database as eligible to be recovered. RMAN considers the incremental backups on disk and tape as eligible to recover the image copies. In a database recovery, RMAN considers only the disk backups associated with the database and all files on tape as eligible to be restored. To illustrate the differences in backup accessibility, assume that databases prod and standby1 reside on different hosts. RMAN backs up datafile 1 on prod to /prmhost/disk1/df1.dbf on the production host and also to tape. RMAN backs up datafile 1 on standby1 to /sbyhost/disk2/df1.dbf on the standby host and also to tape. If RMAN is connected to database prod, then you cannot use RMAN commands to perform operations with the /sbyhost/disk2/df1.dbf backup located on the standby host. However, RMAN does consider the tape backup made on standby1 as eligible to be restored. Note: You can FTP a backup from a standby host to a primary host or vice versa, connect as TARGET to the database on this host, and then CATALOG the backup. After a file is cataloged by the target database, the file is associated with the target database.
Starting & Interacting with RMAN Client
Page 79 of 212
11. Starting and Interacting with the RMAN Client

11.1 Starting and Exiting RMAN
The RMAN executable is automatically installed with the database and is typically located in the same directory as the other database executables. For example, the RMAN client on Linux is located in $ORACLE_HOME/bin. You have the following basic options for starting RMAN: Start the RMAN executable at the operating system command line without specifying any connection options, as in the following example: % rman Start the RMAN executable at the operating system command line while connecting to a target database and, possibly, a recovery catalog, as in the following examples: % rman TARGET / # operating system authentication % rman TARGET SYS@prod NOCATALOG % rman TARGET / CATALOG rco@catdb # RMAN prompts for SYS password # RMAN prompts for rco password
Note: Most RMAN commands require that RMAN connect to at least a target database to perform useful work. To quit RMAN and terminate the program, enter EXIT or QUIT at the RMAN prompt: RMAN> EXIT
11.2 Specifying the Location of RMAN Output

By default, RMAN writes command output to standard output. To redirect output to a log file, enter the LOG parameter on the command line when starting RMAN, as in the following example: % rman LOG /tmp/rman.log In this case, RMAN displays command input but does not display the RMAN output. The easiest way to send RMAN output both to a log file and to standard output is to use the Linux tee command or its equivalent. For example, the following technique enables both input and output to be visible in the RMAN command-line interface: % rman | tee rman.log RMAN> Setting Globalization Support Environment Variables for RMAN Before invoking RMAN, it may be useful to set the NLS_DATE_FORMAT and NLS_LANG environment variables. These variables determine the format used for the time parameters in RMAN commands such as RESTORE, RECOVER, and REPORT. The following example shows typical language and date format settings: NLS_LANG=american NLS_DATE_FORMAT='Mon DD YYYY HH24:MI:SS' If you are going to use RMAN to connect to an unmounted database and mount the database later while RMAN is still connected, then set the NLS_LANG environment variable so that it also specifies the character set used by the database. A database that is not mounted assumes the default character set, which is US7ASCII. If your character set is different from the default, then RMAN returns errors after the database is mounted. For example, if the character set is WE8DEC, then you can set the NLS_LANG variable as follows: NLS_LANG=american_america.we8dec NLS_LANG and NLS_DATE_FORMAT must be set for NLS_DATE_FORMAT to be used.
Page 80 of 212
11.3 Entering RMAN Commands

11.3.1 Entering RMAN Commands at the RMAN Prompt
When the RMAN client is ready for your commands, it displays the command prompt, as in this example: RMAN> Enter commands for RMAN to execute. For example: RMAN> CONNECT TARGET RMAN> BACKUP DATABASE; Most RMAN commands take a number of parameters and must end with a semicolon. Some commands, such as STARTUP, SHUTDOWN, and CONNECT, can be used with or without a semicolon. When you enter a line of text that is not a complete command, RMAN prompts for continuation input with a line number. For example: RMAN> BACKUP DATABASE 2> INCLUDE CURRENT 3> CONTROLFILE 4>;
11.3.2 Using Command Files with RMAN

For repetitive tasks, you can create a text file containing RMAN commands, and start the RMAN client with the @ argument, followed by a filename. For example, create a text file cmdfile1 in the current directory contained one line of text as shown here: BACKUP DATABASE PLUS ARCHIVELOG; You can run this command file from the command line as shown in this example, and the command contained in it is executed: % rman TARGET / @cmdfile1 After the command completes, RMAN exits. You can also use the @ command at the RMAN command prompt to execute the contents of a command file during an RMAN session. RMAN reads the file and executes the commands in it. For example: RMAN> @cmdfile1 After the command file contents have been executed, RMAN displays the following message: RMAN> **end-of-file** Unlike the case where a comma nd file is executed from the operating system command line, RMAN does not exit.
11.3.3 Entering Comments in RMAN Command Files

The comment character in RMAN is a pound sign (#). All text from the pound sign to the end of the line is ignored. For example, the following command file contents backs up the database and archived redo log files and includes comments: # Command file name: mybackup.rman # The following command backs up the database BACKUP DATABASE; # The following command backs up the archived redo logs BACKUP ARCHIVELOG ALL; The following example shows that you can break a single RMAN command across multiple lines: RMAN> BACKUP # this is a comment 2> SPFILE;
Starting backup at 30-APR-07

Starting & Interacting with RMAN Client allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=118 device type=DISK channel ORA_DISK_1: starting full datafile backup set channel ORA_DISK_1: specifying datafile(s) in backup set including current SPFILE in backup set channel ORA_DISK_1: starting piece 1 at 30-APR-07 channel ORA_DISK_1: finished piece 1 at 30-APR-07 piece
Page 81 of 212
handle=/disk2/PROD/backupset/2007_04_30/o1_mf_nnsnf_TAG20070430T101234_33d8wgbj_.bkp tag=TAG20070430T101234 comment=NONE channel ORA_DISK_1: backup set complete, elapsed time: 00:00:01 Finished backup at 30-APR-07
Starting Control File and SPFILE Autobackup at 30-APR-07 piece handle=/disk1/oracle/dbs/c-32126750-20070430-00 comment=NONE Finished Control File and SPFILE Autobackup at 30-APR-07
11.3.4 Using Substitution Variables in Command Files

When running a command file, you can specify one or more values in a USING clause for use in substitution variables in a command file. In this way, you can make your command files dynamic. As in SQL*Plus, &1 indicates where to place the first value, &2 where to place the second value, and so on. The substitution variable syntax is &integer followed by an optional period, for example, &1.3. The optional period is part of the variable and replaced with the value, thus enabling the substitution text to be immediately followed by another integer. For example, if you pass the value mybackup to a command file containing the variable &1.3, then the result of the substitution is mybackup3. The following procedure explains how to create and use a dynamic shell script that calls a command file containing substitution variables. To create and use a dynamic shell script: 1. Create an RMAN command file that uses substitution variables. The following example shows the contents of a command file named quarterly_backup.cmd. The script uses substitution variables for the name of the tape set, for a string in the FORMAT specification, and for the name of the restore point to be created. # quarterly_backup.cmd
CONNECT TARGET / RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=&1)'; BACKUP DATABASE TAG &2 FORMAT '/disk2/bck/&1%U.bck' KEEP FOREVER RESTORE POINT &3; } EXIT;
Page 82 of 212
2. Create a shell script that you can use to run the RMAN command file created in the previous step. The following example creates a shell script named runbackup.sh. The example creates shell variables for the format and restore point name and accepts the values for these variables as command-line arguments to the script. #!/bin/tcsh # name: runbackup.sh # usage: use the tag name and number of copies as arguments set media_family = $argv[1] set format = $argv[2] set restore_point = $argv[3] rman @'/disk1/scripts/whole_db.cmd' USING $media_family $format $restore_point 3. Every quarter, execute the shell script created in the previous step, specifying the desired arguments on the command line. The following example runs the runbackup.sh shell script and passes it archival_backup as the media family name, bck0906 as the format string, and FY06Q3 as the restore point name. % runbackup.sh archival_backup bck0906 FY06Q3
11.4 Checking RMAN Syntax

You may want to test RMAN commands for syntactic correctness without executing them. Use the command-line argument CHECKSYNTAX to start the RMAN client in a mode in which it only parses the commands you enter and returns an RMAN-00558 error for commands that are not legal RMAN syntax.
11.4.1 Checking RMAN Syntax at the Command Line

You can check the syntax of RMAN commands interactively without actually executing the commands. To check RMAN syntax at the command line: 1. Start RMAN with the CHECKSYNTAX parameter. For example, enter the following commands: % rman CHECKSYNTAX 2. Enter the RMAN commands to be tested. The following shows a sample interactive session, with user-entered text in bold. RMAN> run [ backup database; ] RMAN-00571: ======================================================== RMAN-00569: ========= ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =============================================== RMAN-00558: error encountered while parsing input commands RMAN-01006: error signalled during parse RMAN-02001: unrecognized punctuation symbol "["
RMAN> run { backup database; } The command has no syntax errors RMAN>
11.4.2 Checking RMAN Syntax in Command Files

To test commands in a command file, start RMAN with the CHECKSYNTAX parameter and use the @ command to name the command file to be passed. To test commands in a command file: 1. Use a text editor to create a command file. Assume that you create the /tmp/goodcmdfile with the following contents: # command file with legal syntax RESTORE DATABASE;
Starting & Interacting with RMAN Client RECOVER DATABASE; Assume that you create another command file, /tmp/badcmdfile, with the following contents: # command file with bad syntax commands RESTORE DATABASE RECOVER DATABASE
Page 83 of 212
2. Run the command file from the RMAN prompt in the following format, where filename is the name of the command file: % rman CHECKSYNTAX @filename The following example shows the output when you run /tmp/goodcmdfile with CHECKSYNTAX: RMAN> # command file with legal syntax 2> restore database; 3> recover database; 4> The cmdfile has no syntax errors Recovery Manager complete. In contrast, the following example shows the output you run /tmp/badcmdfile with CHECKSYNTAX: Making Database Connections with RMAN RMAN> #command file with syntax error 2> restore database 3> recover RMAN-00571: ======================================================== RMAN-00569:========= ERROR MESSAGE STACK FOLLOWS=============== RMAN-00571: =============================================== RMAN-00558: error encountered while parsing input commands RMAN-01005: syntax error: found "recover": expecting one of: "archivelog, channel, check, controlfile, clone, database, datafile, device, from, force, high, (, preview, ;, skip, spfile, standby, tablespace, until, validate" RMAN-01007: at line 3 column 1 file: /tmp/badcmdfile You make your command files dynamic by including substitution variables. When you check the syntax of a command file that contains substitution variables, RMAN prompts you to enter values. Example illustrates what happens you enter invalid values when checking the syntax of a dynamic command file. The text in bold indicates text entered as the prompt. Example - Checking the Syntax of a Command File with Bad Syntax RMAN> CONNECT TARGET * 2> BACKUP TAG Enter value for 1: mybackup abc COPIES Enter value for 2: mybackup abc RMAN-00571: ======================================================== RMAN-00569:========= ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =============================================== RMAN-00558: error encountered while parsing input commands
Starting & Interacting with RMAN Client RMAN-01009: syntax error: found "identifier": expecting one of: "integer" RMAN-01008: the bad identifier was: mybackup RMAN-01007: at line 2 column 25 file: /tmp/whole_db.cmd RMAN indicates a syntax error because the string mybackup is not a valid argument for COPIES.
Page 84 of 212
11.4.3 Making Database Connections with RMAN

About RMAN Database Connections To perform useful work, the RMAN client must connect to a database. The following table describes the types of database connections that you can make with RMAN. Overview of RMAN Database Connections
Authentication for RMAN Database Connections RMAN connections to a database are specified and authenticated in the same way as SQL*Plus connections to a database. The only difference is that RMAN connections to a target or auxiliary database require the SYSDBA privilege. The AS SYSDBA keywords are implied for target and auxiliary connections and cannot be explicitly specified. A SYSDBA privilege is not required when connecting to the recovery catalog. Note that you must grant the RECOVERY_CATALOG_OWNER role to the catalog schema owner. Authentication for RMAN Database Connections Using the Operating System To connect to a database using operating system authentication, you must set the environment variable specifying the Oracle SID. For example, to set the SID to prod in some UNIX shells, you would enter: % ORACLE_SID=prod; export ORACLE_SID A special operating system groups controls SYSDBA connections when using operating system authentication. This group is generically referred to as OSDBA. The group is created and assigned a specific name as part of the database installation process. The specific name varies depending upon your operating system. If the current operating system user is a member of the OSDBA group, and if the Oracle SID is set, then RMAN can connect to this database with SYSDBA privileges as follows: % rman TARGET / Authentication for RMAN Database Connections Using a Password File If a database uses a password file, and then RMAN can use a password to connect to this database. Use a password file for either local or remote access. You must use a password file if you are connecting remotely as SYSDBA with a net service name.
Page 85 of 212
Caution: Good security practice requires that passwords should not be entered in plain text on the command line. You should enter passwords in RMAN only when requested by an RMAN prompt. You can start RMAN without a password in the connect string, as in this example: % rman TARGET SYS@prod
target database Password: password connected to target database: PROD1 (DBID=39525561) RMAN prompts for a password and does not echo the characters.
11.4.4 Making RMAN Database Connections from the Operating System Command Line
To connect to a target database from the operating system command line, enter the rman command followed by the connection information. You can begin executing commands after the RMAN prompt is displayed. Example - Connecting to a Target Database from the System Prompt % rman TARGET / NOCATALOG connected to target database: PROD (DBID=39525561) using target database control file instead of recovery catalog RMAN> Example illustrates a connection to a target database that uses Oracle Net authentication. RMAN prompts for the password. Example - Connecting to a Target Database from the System Prompt % rman TARGET SYS@prod NOCATALOG target database Password: password connected to target database: PROD (DBID=39525561) RMAN> Use the CATALOG keyword to connect to a recovery catalog. Example illustrates a connection that uses Oracle Net authentication for the target and recovery catalog databases. In both cases RMAN prompts for a password. Example -Connecting to Target and Catalog Databases from the System Prompt % rman TARGET SYS@prod CATALOG rco@catdb target database Password: password connected to target database: PROD (DBID=39525561) recovery catalog database Password: password connected to recovery catalog database RMAN> You can also start RMAN without specifying NOCATALOG or CATALOG. If you do not specify NOCATALOG on the command line, and if you do not specify CONNECT CATALOG after RMAN has started, then RMAN defaults to NOCATALOG mode the first time that you run a command that requires the use of the RMAN repository. Note: After you have executed a command that uses the RMAN repository in NOCATALOG mode, you must exit and restart RMAN to be able to connect to a recovery catalog. If you connect to the target database on the operating system command line, then you can begin executing commands after the RMAN prompt is displayed.
11.4.5 Making Database Connections from the RMAN Prompt

If you start RMAN without connecting to a target database, then you must issue a CONNECT TARGET command at the RMAN prompt to connect to a target database and begin performing useful work.
Page 86 of 212
To make a database connection from the RMAN prompt: 1. On the operating system command line, start the RMAN client without making a database connection. For example, enter rman as follows: % rman RMAN> 2. At the RMAN prompt, enter one or more CONNECT commands. The following example connects to a target database using operating system authentication: RMAN> CONNECT TARGET / The following alternative example connects to a target database and then a recovery catalog. The target connection uses operating system authentication, whereas the catalog database connection uses Oracle Net authentication. RMAN prompts for the password of the recovery catalog user. RMAN> CONNECT TARGET / RMAN> CONNECT CATALOG rco@catdb recovery catalog database Password: password connected to recovery catalog database The following example connects to a target database with database-level credentials. RMAN prompts for the SYS password. % rman RMAN> CONNECT TARGET SYS@prod target database Password: password connected to target database: PROD (DBID=39525561)
11.4.6 Connecting RMAN to an Auxiliary Database

To use the DUPLICATE command, you need to connect to an auxiliary instance. To perform RMAN tablespace point-in-time recovery (TSPITR), you may also need to connect to an auxiliary instance. The form of an auxiliary connection is identical to connect a target database connection, except that you use the AUXILIARY keyword instead of the TARGET keyword. Example connects to a target database and auxiliary instance from the RMAN prompt. Example Connecting to the Target and Catalog Databases from the RMAN Prompt % rman RMAN> CONNECT TARGET / RMAN> CONNECT AUXILIARY SYS@aux auxiliary database Password: password connected to auxiliary database: PROD (DBID=30472568)
11.4.7 Making RMAN Database Connections within Command Files

If you create an RMAN command file which uses a CONNECT command with database level credentials (user name and password), then anyone with read access to this file can learn the password. There is no secure way to incorporate a CONNECT string with a password into a command file. You create an RMAN command file which uses a CONNECT command, then RMAN does not echo the connect string when you run the command file with the @ command. This behavior prevents connect strings from appearing in any log files that contain RMAN output. For example, suppose you create a command file listbkup.rman as follows: cat > listbkup.rman << EOF CONNECT TARGET / LIST BACKUP; EOF You execute this script by running RMAN with the @ command line option as follows: % rman @listbkup.rman When the command file executes, RMAN replaces the connection string with an asterisk, as shown in the following output:
Starting & Interacting with RMAN Client RMAN> CONNECT TARGET * 2> LIST BACKUP; 3> connected to target database: RDBMS (DBID=771530996) using target database control file instead of recovery catalog List of Backup Sets =================== . . .
Page 87 of 212
11.5 Diagnosing RMAN Connection Problems

When diagnosing errors RMAN encounters in connecting to the target, catalog and auxiliary databases, using SQL*Plus to connect to the databases directly can reveal underlying problems with the connection information or the databases.
11.5.1 Diagnosing Target and Auxiliary Database Connection Problems

RMAN always connects to target and auxiliary databases using the SYSDBA privilege. Thus, when using SQL*Plus to diagnose connection problems to the target or auxiliary databases, request a SYSDBA connection to reproduce RMAN behavior. For example, suppose that the following RMAN command encountered connection errors: RMAN> CONNECT TARGET / You could reproduce the preceding connection attempt with the SQL*Plus command as follows: SQL> CONNECT / AS SYSDBA
11.5.2 Diagnosing Recovery Catalog Connection Problems

When RMAN connects to the recovery catalog database, it does not use the SYSDBA privilege. So, when you are using SQL*Plus to diagnose connection problems to the recovery catalog database, you must enter the database connect string exactly as it was entered into RMAN. Do not specify AS SYSDBA.
Configuring the RMAN Environment
Page 88 of 212
12. Configuring the RMAN Environment

12.1 Configuring the Environment for RMAN Backups
For most parameters required for backups, RMAN provides sensible defaults that enable you to perform basic backup and recovery. When implementing an RMAN-based backup strategy, you can use RMAN more effectively if you understand the more common configurations. To simplify ongoing use of RMAN, you can set a number of persistent configuration settings for each target database. These settings control many aspects of RMAN behavior. For example, you can configure the backup retention policy, default destinations for backups, default backup device type, and so on. You can use the SHOW and CONFIGURE commands to view and change RMAN configurations. This section explains what an RMAN configuration is and how you can use the CONFIGURE command to change RMAN default behavior for your backup and recovery environment. This section also introduces the major settings available to you and their most common values.
12.2 Showing and Clearing Persistent RMAN Configurations

You can use the SHOW command to display the current value of RMAN configured settings for the target database. You can also view whether these commands are currently set to their default values.To view or change your CONFIGURE command settings: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Run the RMAN SHOW command. For example, run SHOW ALL as shown in Example (sample output included). The output includes parameters you have changed and that are set to the default. The configuration is displayed as the series of RMAN commands required to re-create the configuration. You can save the output in a text file and use this command file to re-create the configuration on the same or a different database. Example - SHOW ALL Command SHOW ALL; RMAN configuration parameters for database with db_unique_name PROD1 are: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 3 DAYS; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE CONTROLFILE AUTOBACKUP ON; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE SBT_TAPE TO '%F'; # default CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '%F'; # default CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE SBT_TAPE TO 1; # default CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_DEVICE=tape1)'; CONFIGURE MAXSETSIZE TO UNLIMITED; # default CONFIGURE ENCRYPTION FOR DATABASE OFF; # default CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
Page 89 of 212
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/disk1/oracle/dbs/snapcf_ev.f'; # default You can also use the SHOW command with the name of a particular configuration. For example, you can view the retention policy and default device type as follows: SHOW RETENTION POLICY; SHOW DEFAULT DEVICE TYPE; 3. Optionally, use the CONFIGURE ... CLEAR command to return any configuration to its default value. You can use the CONFIGURE ... CLEAR command as shown in the following examples: CONFIGURE BACKUP OPTIMIZATION CLEAR; CONFIGURE RETENTION POLICY CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR;
12.3 Configuring the Default Device for Backups: Disk or SBT

Backups for which no destination device type is specified are directed to the configured default device. RMAN is preconfigured to use disk as the default device type. No additional configuration is necessary. You may need to change the default device type from disk to tape, or change it back from tape to disk. To change the configured default device type: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Run the SHOW ALL command to show the currently configured default device. 3. Run the CONFIGURE DEFAULT DEVICE TYPE command, specifying either TO DISK or TO sbt.
12.3.1 Configuring the Default Type for Backups: Backup Sets or Copies
The BACKUP command can create either backup sets or image copies. For disk, you can configure RMAN to create either backup sets or image copies as its default backup type with the CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO command. The default backup type for disk is an uncompressed backup set. Note: Because RMAN can write an image copy only to disk, the backup type for tape can only be a backup set. RMAN can create backup sets using binary compression. You can configure RMAN to use compressed backup sets by default on a device type by specifying the COMPRESSED option in the BACKUP TYPE TO ... BACKUPSET clause. To disable compression, use the CONFIGURE DEVICE TYPE command with arguments specifying your other desired settings, but omit the COMPRESSED keyword.
To configure the default type of backup: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Configure backup sets or image copies as the default backup type. The following examples configure the backup type for disk backups to copies and backup sets: CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COPY; # image copies CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO BACKUPSET; # uncompressed The following examples configure compression for backup sets: CONFIGURE DEVICE TYPE DISK BACKUP TYPE TO COMPRESSED BACKUPSET; CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO COMPRESSED BACKUPSET;
12.4 Configuring Channels

An RMAN channel is a connection to a database server session. RMAN uses channels to perform almost all RMAN tasks.
Page 90 of 212
12.4.1 About Channel Configuration

Use the CONFIGURE CHANNEL command to configure options for disk or SBT channels. CONFIGURE CHANNEL takes the same options used to specify one-time options with the ALLOCATE CHANNEL command. You can configure generic channel settings for a device type, that is, a template that is used for any channels created based on configured settings for that device. Note that if you use CONFIGURE CHANNEL to specify generic channel settings for a device, any previous settings are discarded, even if the settings are not in conflict. For example, after the second CONFIGURE CHANNEL command, which specifies only the FORMAT for configured disk channels, the MAXPIECESIZE for the disk channel is returned to its default value: CONFIGURE CHANNEL DEVICE TYPE DISK MAXPIECESIZE 2G; CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT /tmp/%U;
12.4.2 Configuring Channels for Disk

By default, RMAN allocates one disk channel for all operations. You may wish to specify different options for this channel, for example, a new default location for backups. Example configures RMAN to write disk backups to the /disk1 directory and specifies a non-default format for the relative filename: Example - Configuring a Non-default Backup Location CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '/disk1/ora_df%t_s%s_s%p'; In Example, RMAN automatically replaces the format specifier %t with a four byte time stamp, %s with the backup set number, and %p with the backup piece number. Note: By configuring an explicit format for disk channels, RMAN does not create backups by default in the flash recovery area. In this case, you lose the disk space management capabilities of the flash recovery area. You can also specify an ASM disk location, as shown in the following example: CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT '+dgroup1';
12.4.3 Configuring Channel Parallelism for Disk and SBT Devices

The number of channels available for a device type when you run a command determines whether RMAN will read or write in parallel. As a rule, the number of channels used in executing a command should match the number of devices accessed. Thus, for tape backups, allocate one channel for each tape drive. For disk backups, allocate one channel for each physical disk, unless you can optimize the backup for your disk subsystem architecture with multiple channels. Failing to allocate the right number of channels adversely affects RMAN performance during I/O operations. You can configure channel parallelism settings, binary compression for backup sets, and other options for an SBT device with CONFIGURE DEVICE TYPE sbt. You set the configuration for the device type independently of the channel configuration. Example changes the parallelism for the SBT device (sample output included) so that RMAN can back up to a media manager using two tape drives in parallel. Each configured SBT channel will back up roughly half the total data. Example - Configuring Parallelism for an SBT Device RMAN> CONFIGURE DEVICE TYPE sbt PARALLELISM 2;
old RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO COMPRESSED BACKUPSET PARALLELISM 1; new RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; new RMAN configuration parameters are successfully stored
Page 91 of 212
Example changes the default backup type for the SBT device to an uncompressed backup set (sample output included). Example - Configuring the Backup Type for an SBT Device RMAN> CONFIGURE DEVICE TYPE sbt BACKUP TYPE TO BACKUPSET; old RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' PARALLELISM 2 BACKUP TYPE TO COMPRESSED BACKUPSET; new RMAN configuration parameters: CONFIGURE DEVICE TYPE 'SBT_TAPE' BACKUP TYPE TO BACKUPSET PARALLELISM 2; new RMAN configuration parameters are successfully stored Note that the CONFIGURE DEVICE TYPE commands used in this example to set parallelism and backup type do not affect the values of settings not specified. In Example, the default backup type of compressed backup set was not changed by changing the parallelism. In Example, the parallelism was not changed by changing the default backup type.
12.4.4 Manually Overriding Configured Channels

If you manually allocate a channel during a job, then RMAN disregards any configured channel settings. For example, assume that the default device type is SBT, and you execute the following command: RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK; BACKUP TABLESPACE users; } In this case, RMAN uses only the disk channel that you manually allocated within the RUN command, overriding any defaults set by using CONFIGURE DEVICE TYPE, CONFIGURE DEFAULT DEVICE, or CONFIGURE CHANNEL settings.
12.5 Configuring Control File & Server Parameter File Autobackups

You can configure RMAN to automatically back up the control file and server parameter file. The autobackup occurs whenever a backup record is added. If the database runs in ARCHIVELOG mode, then an autobackup is also taken whenever the database structure metadata in the control file changes. A control file autobackup enables RMAN to recover the database even if the current control file, recovery catalog, and server parameter file are lost. Because the filename for the autobackup follows a well-known format, RMAN can search for it without access to a repository and then restore the server parameter file. After you have started the instance with the restored server parameter file, RMAN can restore the control file from an autobackup. After you mount the control file, the RMAN repository is available and RMAN can restore the datafiles and find the archived redo logs. You can enable the autobackup feature by running the following command: CONFIGURE CONTROLFILE AUTOBACKUP ON; You can disable the feature by running the following command: CONFIGURE CONTROLFILE AUTOBACKUP OFF;
12.5.1 Configuring the Control File Autobackup Format

By default, the format of the autobackup file for all configured devices is the substitution variable %F in the FORMAT clause. This variable format translates into c-IIIIIIIIII-YYYYMMDD-QQ, with the placeholders defined as follows: IIIIIIIIII stands for the DBID. YYYYMMDD is a time stamp of the day the backup is generated.
Configuring the RMAN Environment QQ is the hex sequence that starts with 00 and has a maximum of FF.
Page 92 of 212
You can change the default format by using the following command, where device Specifier is any valid device type, and 'string' must contain the substitution variable %F (and no other substitution variables) and is a valid handle for the specified device: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE deviceSpecifier TO 'string'; For example, you can run the following command to specify a nondefault filename for the control file autobackup: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '?/oradata/cf_%F'; The following example configures the autobackup to write to an Automatic Storage Management disk group: CONFIGURE CONTROLFILE AUTOBACKUP FOR DEVICE TYPE DISK TO '+dgroup1/%F'; To clear control file autobackup formats for a device, use the following commands: CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK CLEAR; CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE sbt CLEAR; If you have set up a flash recovery area for the database, then you can direct control file autobackups to the flash recovery area by clearing the control file autobackup format for disk.
12.5.2 Overriding the Configured Control File Autobackup Format

The SET CONTROLFILE AUTOBACKUP FORMAT command, which you can specify either within a RUN command or at the RMAN prompt, overrides the configured autobackup format in the current session only. The order of precedence is: 1. SET CONTROLFILE AUTOBACKUP FORMAT (within a RUN block) 2. SET CONTROLFILE AUTOBACKUP FORMAT (at RMAN prompt) 3. CONFIGURE CONTROLFILE AUTOBACKUP FORMAT The following example shows how the two forms of SET CONTROLFILE AUTOBACKUP FORMAT interact: SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'controlfile_%F'; BACKUP AS COPY DATABASE; RUN { SET CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/tmp/%F.bck'; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; } The first SET CONTROLFILE AUTOBACKUP FORMAT controls the name of the control file autobackup until the RMAN client exits, overriding any configured control file autobackup format. The SET CONTROFILE AUTOBACKUP FORMAT in the RUN block overrides the SET CONTROLFILE AUTOBACKUP FORMAT outside the RUN block for the duration of the RUN block.
12.6 Configuring RMAN to Make Backups to a Media Manager

On most platforms, to back up to and restore from sequential media such as tape you must integrate a media manager with your Oracle database. You can use Oracle Secure Backup, which supports both database and file
Page 93 of 212
system backups to tape, as your media manager. You should refer to Oracle Secure Backup Administrator's Guide to learn how to set up RMAN for use specifically with Oracle Secure Backup. If you do not use Oracle Secure Backup, then you can use a third-party media manager. This section describes the generic steps for configuring RMAN for use with a third-party media manager. The actual steps depend on the media management product that you install and the platform on which you are running the database. If you choose to use RMAN with a media manager other than Oracle Secure Backup, then you must obtain all product-specific information from the vendor. Read the following sections in order when configuring the media manager: 1. Prerequisites for Using a Media Manager with RMAN 2. Determining the Location of the Media Management Library 3. Configuring Media Management Software for RMAN Backups 4. Testing Whether the Media Manager Library Is Integrated Correctly 5. Configuring SBT Channels for Use with a Media Manager
12.6.1 Prerequisites for Using a Media Manager with RMAN

Before you can begin using RMAN with a third-party media manager, you must install it and make sure that RMAN can communicate with it. Refer to the media management vendor's software documentation for instructions. In general, you should begin by installing and configuring the media management software on the target host or production network. Ensure that you can make non-RMAN backups of operating system files on the target database host. This step makes later troubleshooting much easier by confirming that the basic integration of the media manager with the target host has been successful. Refer to your media management documentation to learn how to back up files to the media manager without using RMAN. Then, obtain and install the third-party media management module for integration with the data base server. This module contains the media management library that the Oracle database loads and uses when accessing the media manager. It is generally a third-party product which must be purchased separately. Contact your media management vendor for details.
12.6.2 Determining the Location of the Media Management Library

Before attempting to use RMAN with a media manager, determine the location of the media management library. When allocating or configuring a channel for RMAN to use to communicate with a media manager, you must specify the SBT_LIBRARY parameter in an ALLOCATE CHANNEL or CONFIGURE CHANNEL command. The SBT_LIBRARY parameter specifies the path to the library. The following example shows the channel syntax, where pathname is the absolute filename of the library: CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'SBT_LIBRARY=pathname'; When RMAN allocates channels to communicate with a media manager, it attempts to load the library indicated by the SBT_LIBRARY parameter. If you do not provide a value for the SBT_LIBRARY parameter in an allocated or preconfigured channel, then RMAN looks in a platform-specific default location. On Linux and UNIX, the default library filename is $ORACLE_HOME/lib/libobk. so, with the extension name varying according to platform: .so, .sl on HP/UNX, .a on AIX, and so on. On Windows the default library location is %ORACLE_HOME%\bin\orasbt.dll. Note: The default media management library file is not part of the standard database installation. It is only present if you install third-party media management software.
12.6.3 Configuring Media Management Software for RMAN Backups

After installing the media management software, perform whatever configuration that your vendor requires so that the software can accept RMAN backups. Depending on the type of media management software that you installed, you may have to define media pools, configure users and classes, and so on. Consult your media management vendor documentation for the appropriate RMAN settings. The PARMS parameter sends instructions to the media manager. If PARMS values are needed for the ALLOCATE CHANNEL or the CONFIGURE CHANNEL command, or if a FORMAT string is recommended for the BACKUP or CONFIGURE command, then refer to the vendor documentation for this information. Example shows a PARMS setting for Oracle Secure Backup. This PARMS
Page 94 of 212
settings nstructs the media manager to back up to a family of tapes called datafile_mf. The PARMS settings are always vendor-specific. Example - PARMS Setting for Oracle Secure Backup CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS 'ENV=(OB_MEDIA_FAMILY=datafile_mf)';
12.6.4 Testing Whether the Media Manager Library Is Integrated Correctly

After you have confirmed that the data base server can load the media management library, test to make sure that RMAN can back up to the media manager. Testing ALLOCATE CHANNEL on the Media Manager The following steps use the ALLOCATE CHANNEL command to perform a basic test that RMAN is able to communicate with the media manager. To test channel allocation on the media manager: 1. Start RMAN and connect to a target database and a recovery catalog (if used).: 2. Run the ALLOCATE CHANNEL command with the PARMS required by your media management software. The following RUN command shows sample vendor-specific PARMS settings: RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so, ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)'; }
3. Examine the RMAN output.
If you do not receive an error message, then the database successfully loaded the media management library. If you receive the ORA-27211 error, the media management library could not be loaded: RMAN-00571: =========================================================== RMAN-00569: ========== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03009: failure of allocate command on c1 channel at 11/30/2007 13:57:18 ORA-19554: error allocating device, device type: SBT_TAPE, device name: ORA-27211: Failed to load Media Management Library Additional information: 25 In this case, you must check the media management installation to make sure that the library is correctly installed, and re-check the value for the SBT_LIBRARY parameter. If the database is unable to locate a media management library in the location specified by the SBT_LIBRARY parameter or the default location, then RMAN issues an ORA27211 error and exits. Whenever channel allocation fails, the database writes a trace file to the trace subdirectory in the Automatic Diagnostic Repository (ADR) home directory. The following shows sample output: SKGFQ OSD: Error in function sbtinit on line 2278 SKGFQ OSD: Look for SBT Trace messages in file /oracle/rdbms/log/sbtio.log SBT Initialize failed for /oracle/lib/libobk.so
Page 95 of 212
12.6.5 Testing Backup and Restore Operations on the Media Manager

After testing a channel allocation on the media manager, create and restore a test backup. For example, you could use the command in Example (substituting the channel settings required by your media management vendor) to test whether a backup can be created on the media manager. If your database does not use a server parameter file, then back up the current control file instead. Example - Backing Up the Server Parameter File to Tape RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so, ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)'; BACKUP SPFILE; # If your database does not use a server parameter file, use: # BACKUP CURRENT CONTROLFILE; } If the backup succeeds, then attempt to restore the server parameter file as an initialization parameter file. Example restores the backup created in Example to a temporary directory. Example - Restoring the Server Parameter File from Tape RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'SBT_LIBRARY=/mydir/lib/libobk.so, ENV=(OB_DEVICE=drive1,OB_MEDIA_FAMILY=datafile_mf)'; RESTORE SPFILE TO PFILE '/tmp/test_restore.f'; # If your database does not use a server parameter file, use: # BACKUP CURRENT CONTROLFILE; } If the backup and restore operations succeed, then you are ready to use the media manager with RMAN. Possible failures include the following cases: The backup hangs. A hanging backup usually indicates that the media manager is waiting to mount a tape. Check if there are any media manager jobs in tape mount request mode and fix the problem. The backup fails with ORA-27211: Failed to load Media Management Library.
This error indicates that the media management software is not correctly configured. Ensure that the steps in "Configuring RMAN to Make Backups to a Media Manager" are correctly done. Also, ensure that you have the correct PARMS and FORMAT strings required by your media management software.
12.7 About Media Manager Backup Piece Names

A backup piece name is determined by the FORMAT string specified in the BACKUP command, CONFIGURE CHANNEL command, or ALLOCATE CHANNEL command. The media manager considers the backup piece name as the name of the backup file, so every backup piece must have a unique name in the media management catalog. You can use the substitution variables in a FORMAT parameter to generate unique backup piece names. For example, %d specifies the name of the database, whereas %t specifies the backup timestamp. For most purposes, you can use %U, in which case RMAN automatically generates a unique filename. The backup piece name 12i1nk47_1_1 is an example. If you do not specify the FORMAT parameter, then RMAN automatically generates a
Page 96 of 212
unique filename with the %U substitution variable. Your media manager may impose restrictions on file names and sizes. In this case, you may need more fine-grained control over the naming of backup pieces so that they obey media manager restrictions. For example, some media managers only support a 14-character backup piece name, and some require special FORMAT strings. Note that the unique names generated by the %U substitution variable do not exceed 14 characters. Note that some media managers may have limits on the maximum size of files that they can back up or restore. You must ensure that RMAN does not produce backup sets larger than those limits. To limit backup piece sizes, use the parameter MAXPIECESIZE, which you can set in the CONFIGURE CHANNEL and ALLOCATE CHANNEL commands.
12.8 Configuring Automatic SBT Channels

The easiest technique for backing up to a media manager is to configure automatic SBT channels. You can use a tape device as your default backup destination. To configure channels for use with a media manager: 1. Configure a generic SBT channel. The following example configures vendor-specific channel parameters and sets the default device: CONFIGURE CHANNEL DEVICE TYPE sbt PARMS 'ENV=(OB_RESOURCE_WAIT_TIME=1minute,OB_DEVICE=tape1)'; 2. Configure the default device type to SBT, as shown in the following command: CONFIGURE DEFAULT DEVICE TYPE TO sbt; The following configuration enables you to back up to two tape drives in parallel: CONFIGURE DEVICE TYPE sbt PARALLELISM 2; Optionally, check your channel configuration by running the following command: SHOW CHANNEL FOR DEVICE TYPE sbt; 3. Make a test backup to tape. The following command backs up the server parameter file to tape: BACKUP SPFILE; 4. List your backups to make sure that the test backup went to the media manager: LIST BACKUP OF SPFILE;
12.9 Configuring the Flash Recovery Area

The flash recovery area feature enables you to set up a disk area where the database can create and manage a variety of files related to backup and recovery. Use of the flash recovery area is strongly recommended. Consider configuring a flash recovery area as one of the first steps in implementing a backup strategy. This section outlines the functions of the flash recovery area, identifies the files stored there, explains the rules for file management, and introduces the most important configuration options.
12.9.1 Overview of the Flash Recovery Area

The flash recovery area can contain control files; online redo logs, archived redo logs, flashback logs, and RMAN backups. Files in the recovery area are permanent or transient. Permanent files are active files used by the database instance. All files that are not permanent are transient. In general, Oracle Database eventually deletes transient files after they become obsolete under the backup retention policy or have been backed up to tape.
12.9.2 Oracle Managed Files and Automatic Storage Management

The flash recovery area can be used in conjunction with Oracle Managed Files (OMF) and Automatic Storage Management (ASM). The flash recovery area is built on top of OMF, so the flash recovery area can be stored anywhere Oracle-managed files can. You can also use the recovery area with ASM. Even if you choose not to set up the flash recovery area in ASM storage, you can still use Oracle Managed Files to manage your backup files in an ASM disk group. You will lose one of the major benefits of the flash recovery area: the automatic deletion of files no longer needed to meet your recoverability goals as space is needed for more recent backups. Nevertheless, the
Page 97 of 212
other automatic features of OMF will still function. When storing backups, using OMF on top of ASM without using a flash recovery area is supported but discouraged. It is awkward to directly manipulate files under ASM.
12.9.3 How Oracle Manages Disk Space in the Flash Recovery Area
Space in the flash recovery area is balanced among backups and archived logs that must be kept according to the retention policy, and other files which may be subject to deletion. Oracle Database does not delete eligible files from the flash recovery area until the space must be reclaimed for some other purpose. Thus, files recently moved to tape are often still available on disk for use in recovery. The recovery area can thus serve as a cache for tape. When the flash recovery area is full, Oracle Database automatically deletes eligible files to reclaim space in the recovery area as needed.
12.9.4 Enabling the Flash Recovery Area

To enable the recovery area, you must set the initialization parameters in Table that are listed as required. Note that in an Oracle Real Application Clusters (Oracle RAC) database, all instances must have the same values for these initialization parameters. The location must be on a cluster file system, ASM, or a shared directory. Table - Initialization Parameters for the Flash Recovery Area
Considerations When Setting the Size of the Flash Recovery Area The larger the flash recovery area is, the more useful it becomes. The recovery area should be able to contain a copy of all datafiles in the database and the incremental backups used by your chosen backup strategy. If providing this much space is impractical, then it is best to create an area large enough to keep a backup of the most important tablespaces and all the archived logs not yet on tape. At an absolute minimum, the flash recovery area must be
Page 98 of 212
large enough to contain the archived redo logs not yet on tape. If the recovery area has insufficient space to store flashback logs and meet other backup retention requirements, then the recovery area may delete flashback logs to make room. Formulas for estimating a useful flash recovery area size depend on whether: Your database has a small or large number of data blocks that change frequently You store backups only on disk, or on disk and tape You use a redundancy-based backup retention policy, or a recovery window-based retention policy You plan to use Flashback Database or a guaranteed restore point as alternatives to point-in-time recovery in response to logical errors If you plan to enable flashback logging, then note that the volume of flashback log generation is approximately the same order of magnitude as redo log generation. For example, if you intend to set DB_FLASHBACK_RETENTION_TARGET to 24 hours, and if the database generates 20 GB of redo in a day, then a rule of thumb is to allow 20 GB to 30 GB disk space for the flashback logs. The same rule applies to guaranteed restore points when flashback logging is enabled. For example, if the database generates 20 GB redo every day, and if the guaranteed restore point will be kept for a day, then plan to allocate 20 to 30 GB. Suppose that you want to determine the size of a flash recovery when the backup retention policy is set to REDUNDANCY 1 and you intend to follow the Oracle Suggested Strategy of using an incrementally updated backup. In this example, you use the following formula to estimate the disk quota, where n is the interval in days between incremental updates and y is the delay in applying the foreign archived redo logs on a logical standby database: Disk Quota = Size of a copy of database + Size of an incremental backup + Size of (n+1) days of archived redo logs + Size of (y+1) days of foreign archived redo logs (for logical standby) + Size of control file + Size of an online redo log member * number of log groups + Size of flashback logs (based on DB_FLASHBACK_RETENTION_TARGET value)
12.9.5 Considerations When Setting the Location of the Flash Recovery Area
Place the flash recovery area on a separate disk from the database area, where the database maintains active database files such as datafiles, control files, and online redo logs. Keeping the flash recovery area on the same disk as the database area exposes you to loss of both your live database files and backups if a media failure occurs. Oracle recommends that DB_RECOVERY_FILE_DEST be set to a different value from DB_CREATE_FILE_DEST or any of the DB_CREATE_ONLINE_LOG_ DEST_n initialization parameters. The database writes a warning to the alert log if DB_RECOVERY_FILE_DEST is the same as these parameters. Multiple databases can have the same value for DB_RECOVERY_FILE_DEST, but one of the following must be true: No two databases for which the DB_UNIQUE_NAME initialization parameters are specified have the same value for DB_UNIQUE_NAME. For those databases where no DB_UNIQUE_NAME is provided, no two databases have the same value for DB_NAME. When databases share a single recovery area in this way, the location should be large enough to hold the files for all databases. Add the values for DB_RECOVERY_FILE_DEST_SIZE for the databases, then allow for overhead such as mirroring or compression.
Page 99 of 212
12.9.6 Setting the Flash Recovery Area Location and Initial Size
This section explains how to specify a location for the recovery area and set its initial size.To determine the optimum size for the flash recovery area: 1. If you plan to use flashback logging or guaranteed restore points, then query V$ARCHIVED_LOG to determine how much redo the database generates in the time to which you intend to set DB_FLASHBACK_RETENTION_TARGET. 2. Set the recovery area size. If you plan to use flashback logging or guaranteed restore points, then ensure that the size value obtained from step 1 is incorporated into the setting. Set the DB_RECOVERY_FILE_DEST_SIZE initialization parameter by any of the following means: Shut down the database and set the DB_RECOVERY_FILE_DEST_SIZE parameter in the initialization parameter file of the database, as shown in the following example: DB_RECOVERY_FILE_DEST_SIZE = 10G Specify them with the SQL statement ALTER SYSTEM SET when the database is open, as shown in the following examples: ALTER SYSTEM SET DB_RECOVERY_FILE_DEST_SIZE = 10G SCOPE=BOTH SID='*'; Use the Database Configuration Assistant to set the size 3. Set the recovery area location. Set the initialization parameters by any of the following means: Set DB_RECOVERY_FILE_DEST in the initialization parameter file of the database, as shown in the following example: DB_RECOVERY_FILE_DEST = '/u01/oradata/rcv_area' Specify DB_RECOVERY_FILE_DEST with the SQL statement ALTER SYSTEM SET when the database is open, as shown in the following example: ALTER SYSTEM SET DB_RECOVERY_FILE_DEST = '+disk1' SCOPE=BOTH SID='*'; Use the Database Configuration Assistant to set the location. If you do not plan to use flashback logging, then open the database (if it is closed) and do not complete the rest of the steps in this procedure. 4. If flashback logging is enabled, then run the database under a normal workload for the time period specified by DB_FLASHBACK_RETENTION_TARGET. In this way, the database can generate a representative sample of flashback logs. 5. Query the V$FLASHBACK_DATABASE_LOG view as follows: SELECT ESTIMATED_FLASHBACK_SIZE FROM V$FLASHBACK_DATABASE_LOG;
The result is an estimate of the disk space needed to meet the current flashback retention target, based on the database workload since Flashback Database was enabled. 6. If necessary, adjust the flashback log space requirement based on the actual size of flashback logs generated during the time period specified by DB_FLASHBACK_RETENTION_TARGET.
12.9.7 Configuring Locations for Control Files and Redo Logs

The only permanent files are multiplexed copies of the current control file and online redo logs. This section explains how to set locations for these files as well as the archived logs.
Page 100 of 212
Configuring Online Redo Log Locations The initialization parameters that determine where online redo log files are created are DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST Details of the effect of combinations of these parameters on online redo log creation can be found in Oracle Database SQL Language Reference in the description of the LOGFILE clause of the CREATE DATABASE statement. The following SQL statements can create online redo logs in the flash recovery area: CREATE DATABASE ALTER DATABASE ADD LOGFILE ALTER DATABASE ADD STANDBY LOGFILE ALTER DATABASE OPEN RESETLOGS
The default size of an online log created in the flash recovery area is 100 MB. The log member filenames are automatically generated by the database. Configuring Control File Locations The initialization parameters CONTROL_FILES, DB_CREATE_ONLINE_LOG_DEST_n, DB_RECOVERY_FILE_DEST, and DB_CREATE_FILE_DEST all interact to determine the location where the database control files are created. If the database creates an Oracle managed control file, and if the database uses a server parameter file, then the database sets the CONTROL_FILES initialization parameter in the server parameter file. If the database uses a client-side initialization parameter file, then you must set the CONTROL_FILES initialization parameter manually in the initialization parameter file. Configuring Archived Redo Log Locations It is recommended that you the use flash recovery area as an archiving location because the archived logs are automatically managed by the database. The generated filenames for the archived logs in the flash recovery area are for Oracle-managed files and are not determined by LOG_ARCHIVE_FORMAT. Whatever archiving scheme you choose, it is always advisable to create multiple copies of archived redo logs. You have the following basic options for archiving redo logs, listed from most to least recommended: 1. Enable archiving to the flash recovery area only and use disk mirroring to create the redundancy needed to protect the archived redo logs. If DB_RECOVERY_FILE_DEST is specified and no LOG_ARCHIVE_DEST_n is specified, then LOG_ARCHIVE_DEST_10 is implicitly set to the recovery area. You can override this behavior by setting LOG_ARCHIVE_DEST_10 to an empty string. 2. Enable archiving to the flash recovery area and set other LOG_ARCHIVE_DEST_n initialization parameter to locations outside the flash recovery area. If a flash recovery area is configured, then you can add the flash recovery area as an archiving destination by setting any LOG_ARCHIVE_DEST_n parameter to LOCATION=USE_DB_RECOVERY_FILE_DEST. 3. Set LOG_ARCHIVE_DEST_n initialization parameters to archive only to non-flash recovery area locations. If you use the flash recovery area, then you cannot use the LOG_ARCHIVE_DEST and LOG_ARCHIVE_DUPLEX_DEST initialization parameters. If you do, then will not be able to start the instance. Instead, set the LOG_ARCHIVE_DEST_n parameters. After your database is using LOG_ARCHIVE_DEST_n, you can configure a recovery area. Note also that if you enable archiving but do not set any value for LOG_ARCHIVE_DEST, LOG_ARCHIVE_DEST_n, or DB_RECOVERY_FILE_DEST, then the redo logs are archived to a default location that is platform-specific. For example, on Solaris the default is ?/dbs. Configuring RMAN File Creation in the Flash Recovery Area This section describes RMAN commands or implicit actions (such as control file autobackups) that can create files in the flash recovery area, and how to control whether a command creates files there or in another destination. The commands are: BACKUP If you do not specify the FORMAT clause for disk backups, then RMAN creates backup pieces and image copies in the flash recovery area, with names in Oracle Managed Files name format. If a flash recovery area is enabled, and
Page 101 of 212
if you do specify FORMAT on BACKUP or a channel, then RMAN creates the backup in a platform-specific location rather than in the recovery area. Control File Autobackup RMAN can create control file autobackups in the flash recovery area. Use the RMAN command CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR %F; DEVICE TYPE DISK CLEAR to clear any configured format option for the control file autobackup location on disk. RMAN creates control file autobackups in the flash recovery area when no other destination is configured. RESTORE ARCHIVELOG Explicitly or implicitly set one of the LOG_ARCHIVE_DEST_n parameters to LOCATION= USE_DB_RECOVERY_FILE_DEST. If you do not specify SET ARCHIVELOG DESTINATION to override this behavior, then RMAN restores archived redo log files to the flash recovery area. RECOVER DATABASE or RECOVER TABLESPACE, RECOVER ... BLOCK, and FLASHBACK DATABASE These commands restore archived redo log files from backup for use during media recovery, as required by the command. RMAN restores any redo log files needed during these operations to the flash recovery area and deletes them after they are applied during media recovery. To direct the restored archived logs to the flash recovery area, set one of the LOG_ARCHIVE_DEST_n parameters to LOCATION = USE_DB_RECOVERY_FILE_DEST. Make sure you are not using SET ARCHIVELOG DESTINATION to direct restored logs to some other destination.
12.10 Configuring the Backup Retention Policy

As explained in "Backup Retention Policies", the backup retention policy specifies which backups must be retained to meet your data recovery requirements. This policy can be based on a recovery window or redundancy. Use the CONFIGURE RETENTION POLICY command to specify the retention policy.
12.10.1 Configuring a Redundancy-Based Retention Policy

The REDUNDANCY parameter of the CONFIGURE RETENTION POLICY command specifies how many backups of each datafile and control file that RMAN should keep. In other words, if the number of backups for a specific datafile or control file exceeds the REDUNDANCY setting, then RMAN considers the extra backups as obsolete. The default retention policy is REDUNDANCY 1. As you produce more backups, RMAN keeps track of which ones to retain and which are obsolete. RMAN retains all archived logs and incremental backups that are needed to recover the non-obsolete backups. Assume that you make a backup of datafile 7 on Monday, Tuesday, Wednesday, and Thursday. You now have four backups of the datafile. If REDUNDANCY is 2, then the Monday and Tuesday backups are obsolete. If you make another backup on Friday, then the Wednesday backup becomes obsolete. Run the CONFIGURE RETENTION POLICY command at the RMAN prompt, as in the following example: CONFIGURE RETENTION POLICY TO REDUNDANCY 3;
12.10.2 Configuring a Recovery Window-Based Retention Policy

The RECOVERY WINDOW parameter of the CONFIGURE command specifies the number of days between the current time and the earliest point of recoverability. RMAN does not consider any full or level 0 incremental backup as obsolete if it falls within the recovery window. Additionally, RMAN retains all archived logs and level 1 incremental backups that are needed to recover to a random point within the window. Run the CONFIGURE RETENTION POLICY command at the RMAN prompt. This example ensures that you can recover the database to any point within the last week: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; RMAN does not automatically delete backups rendered obsolete by the recovery window. Instead, RMAN shows them as OBSOLETE in the REPORT OBSOLETE output and in the OBSOLETE column of V$BACKUP_FILES. RMAN deletes obsolete files if you run the DELETE OBSOLETE command.
Page 102 of 212
12.10.3 Disabling the Retention Policy

When you disable the retention policy, RMAN does not consider any backup as obsolete. To disable the retention policy, run this command: CONFIGURE RETENTION POLICY TO NONE; Configuring the retention policy to NONE is not the same as clearing it. Clearing it returns it to its default setting of REDUNDANCY 1, whereas NONE disables it. If you disable the retention policy and run REPORT OBSOLETE or DELETE OBSOLETE without passing a retention policy option to the command, then RMAN issues an error because no retention policy exists to determine which backups are obsolete. Note: If you are using a flash recovery area, then you should not run your database with the retention policy disabled. If files are never considered obsolete, then a file can only be deleted from the flash recovery area if it has been backed up to some other disk location or to a tertiary storage device such as tape. It is likely that all of the space in your recovery area will be used, which interferes with the normal operation of your database.
12.11 Configuring Backup Optimization

Run the CONFIGURE command to enable and disable backup optimization. Backup optimization skips the backup of files in certain circumstances if the identical file or an identical version of the file has already been backed up.
12.11.1 Overview of Backup Optimization

If you enable backup optimization, then the BACKUP command skips backing up files when the identical file has already been backed up to the specified device type. Table describes criteria that RMAN uses to determine whether a file is identical to a file that it already backed up. Table -Criteria to Determine an Identical File
If RMAN determines that a file is identical and it has already been backed up, then it is a candidate to be skipped. RMAN must do further checking to determine whether to skip the file, however, because both the retention policy and the backup duplexing feature are factors in the algorithm that determines whether RMAN has sufficient backups on the specified device type. RMAN uses backup optimization when the following conditions are true: The CONFIGURE BACKUP OPTIMIZATION ON command has been run to enable backup optimization. You run BACKUP DATABASE, BACKUP ARCHIVELOG with ALL or LIKE options, or BACKUP BACKUPSET ALL, BACKUP RECOVERY AREA, BACKUP RECOVERY FILES, or BACKUP DATAFILECOPY. Only one type of channel is allocated, that is, you do not mix disk and SBT channels in the same backup command. Note: In backup undo optimization, RMAN excludes undo that is not needed for recovery of a backup, that is, for transactions have already been committed. You can enable and disable backup optimization, but backup undo optimization is built-in behavior. Assume that you have configured backup optimization. Example illustrates a session in which back up the database, all archived logs, and all backup sets to tape.
Configuring the RMAN Environment Example -Specifying the Device Type on the BACKUP Command BACKUP DEVICE TYPE sbt DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL;
Page 103 of 212
If none of the backed-up files in Example has changed since the last backup, then RMAN does not back up the files again. RMAN also does not signal an error if it skips all files specified in the command because the files have already been backed up. You can override optimization at any time by specifying the FORCE option on the BACKUP command. For example, you can run: BACKUP DATABASE FORCE; BACKUP ARCHIVELOG ALL FORCE; Effect of Retention Policies on Backup Optimization for SBT Backups Backup optimization is not always applied when backing up to SBT devices. The exceptions to normal backup optimization behavior for recovery window-based and redundancy-based retention policies are described in the following sections. Note: Use caution when enabling backup optimization if you use a media manager with its own internal expiration policy. Run the CROSSCHECK command periodically to synchronize the RMAN repository with the media manager. Otherwise, RMAN may skip backups due to optimization without recognizing that the media manager has discarded backups stored on tape. Backup Optimization for SBT Backups with Recovery Window Retention Policy Suppose that backup optimization is enabled, and a recovery window backup retention policy is in effect. In this case, when performing SBT backup s RMAN always backs up datafiles whose most recent backup is older than the recovery window. For example, assume the following scenario: Today is February 21. The recovery window is 7 days. The most recent backup of tablespace tools to tape is January 3. Tablespace tools is read-only.
On February 21, when you issue a command to back up tablespace tools to tape, RMAN backs it up even though it did not change after the January 3 backup (because it is read-only). RMAN makes the backup because no backup of the tablespace exists within the 7-day recovery window. This behavior enables the media manager to expire old tapes. Otherwise, the media manager would be forced to keep the January 3 backup of tablespace tools indefinitely. By making a more recent backup of tablespace tools on February 21, RMAN enables the media manager to expire the tape containing the January 3 backup. Backup Optimization for SBT Backups with Redundancy Retention Policy Assume that you configure a retention policy for redundancy. In this case, RMAN only skips backups of offline or read-only datafiles to SBT when there are r + 1 backups of the files, where r is set in CONFIGURE RETENTION POLICY TO REDUNDANCY .For example, assume that you enable backup optimization and set the following retention policy: CONFIGURE DEFAULT DEVICE TYPE TO sbt; CONFIGURE BACKUP OPTIMIZATION ON; CONFIGURE RETENTION POLICY TO REDUNDANCY 2; With these settings, RMAN only skips backups when three identical files are already backed up. Also assume that you have never backed up the users tablespace, which is read/write, and that you perform the actions. By default, backup optimization is configured to OFF. You can use the SHOW BACKUP OPTIMIZATION command to view the current settings of backup optimization.
Page 104 of 212
To configure backup optimization: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Run the SHOW BACKUP OPTIMIZATION command to determine whether optimization is currently enabled. For example, enter the following command: SHOW BACKUP OPTIMIZATION; Sample output for SHOW BACKUP OPTIMIZATION follows: RMAN configuration parameters for database with db_unique_name PROD1 are: CONFIGURE BACKUP OPTIMIZATION ON; 3. Enable backup optimization by running the following command: CONFIGURE BACKUP OPTIMIZATION ON;
12.12 Configuring an Archived Redo Log Deletion Policy

You can use RMAN to create a persistent configuration that governs when archived redo logs are eligible for deletion from disk.
12.12.1. About Archived Redo Log Deletion Policies

You can use the CONFIGURE ARCHIVELOG DELETION POLICY command to specify when archived redo logs are eligible for deletion. This deletion policy applies to all archiving destinations, including the flash recovery area. Archived redo logs can be deleted automatically by the database or as a result of user-initiated RMAN commands. Only logs in the flash recovery area can be deleted automatically by the database. For archived redo log files in the flash recovery area, the database retains them as long as possible and automatically deletes eligible logs when additional disk space is required. You can manually delete eligible logs from any location, whether inside or outside the flash recovery area, when you issue BACKUP ... DELETE INPUT or DELETE ARCHIVELOG.
12.12.2. When the Archived Redo Log Deletion Policy Is Disabled

The archived redo log deletion policy is configured to NONE by default. In this case, RMAN considers archived redo log files in the recovery area as eligible for deletion if they meet both of the following conditions: The archived redo logs, whether in the flash recovery area or outside of it, have been transferred to the required remote destinations specified by LOG_ARCHIVE_DEST_n. The archived redo logs have been backed up at least once to disk or SBT or the logs are obsolete according to the backup retention policy. The backup retention policy considers logs obsolete only if the logs are not needed by a guaranteed restore point and the logs are not needed by Oracle Flashback Database. Archived redo logs are needed by Flashback Database if the logs were created later than SYSDATE-'DB_FLASHBACK_ RETENTION_TARGET'.
12.12.3. When the Archived Redo Log Deletion Policy Is Enabled

You can use the CONFIGURE ARCHIVELOG DELETION POLICY BACKED UP integer TIMES TO DEVICE TYPE command to enable an archived log deletion policy. This configuration specifies that archived logs are eligible for deletion only when the specified number of archived log backups exists on the specified device type. If the deletion policy is configured with the BACKED UP integer TIMES clause, then a BACKUP ARCHIVELOG command copies the logs unless integer backups already exist on the specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVELOG command skips the logs. In this way, the archived log deletion policy functions as a default NOT BACKED UP integer TIMES clause on the BACKUP ARCHIVELOG command. Note that you can override the deletion policy by specifying the FORCE option on the BACKUP command.
Page 105 of 212
The archived log deletion policy also has options specific to a Data Guard environment. For example, if you specify the APPLIED ON STANDBY clause, then RMAN can delete logs after they have been applied at all mandatory remote destinations. If you specify SHIPPED TO STANDBY, for example, then RMAN can delete logs when they have been transferred to all mandatory standby destinations. Enabling an Archived Redo Log Deletion Policy This section explains how to configure an archived redo log deletion policy. By default the policy is set to NONE. To enable an archived redo log deletion policy: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Run the CONFIGURE ARCHIVELOG DELETION POLICY command with the desired options. The following example specifies that archived redo logs are eligible to be deleted from the flash recovery area and all local archiving destinations when logs have been backed up at least once to tape: CONFIGURE ARCHIVELOG DELETION POLICY TO BACKED UP 2 TIMES TO SBT;
12.13 Configuring Oracle Flashback Database and Restore Points

This section describes how to plan and configure the environment for Oracle Flashback Database. This section also explains how to create restore points.
12.13.1. About Restore Points and Flashback Database

Oracle Flashback Database and restore points are related data protection features. These features provide more efficient alternatives to point-in-time recovery for reversing unwanted database changes. Flashback Database enables you to rewind an entire database backward in time, reversing the effects of database changes within a time window. The effects are similar to database point-in-time recovery (DBPITR).Restore points provide capabilities related to Flashback Database and other media recovery operations. In particular, a guaranteed restore point created at an SCN ensures that you can use Flashback Database to rewind the data base to this SCN. You can use restore points and Flashback Database independently or together.
12.13.2. Flashback Database

Oracle Flashback Database is accessible through the RMAN command FLASHBACK DATABASE or through the SQL statement FLASHBACK DATABASE. You can use either command to quickly recover the database from logical data corruptions or user errors. Flashback Database is similar to conventional point-in-time recovery in its effects, enabling you to return a database to its state at a time in the recent past. Flashback Database is much faster than point-in-time recovery; however, because it does not require restoring datafiles from backup and requires applying fewer changes from the archived redo logs. You can use Flashback Database to reverse most unwanted changes to a database as long as the datafiles are intact. You can even return a database to its state in a previous incarnation, that is, undo the effects of an ALTER DATABASE OPEN RESETLOGS statement. Flashback Database uses its own logging mechanism, creating flashback logs and storing them in the flash recovery area. You can only use Flashback Database if flashback logs are available. Thus, to take advantage of this feature you must set up your database in advance to create flashback logs. To enable Flashback Database, you configure a flash recovery area and set a flashback retention target. This retention target specifies how far back you can rewind a database with Flashback Database. From the target time onwards, the database regularly copies images of every changed block in the datafiles to the flashback logs. When you use Flashback Database to rewind a database to a past target time, the command determines which blocks changed after the target time and restores them from the flashback logs. The database restores the version of each block that is most immediately prior to the target time. The database then uses redo logs to reapply changes that were made after these blocks were written to the flashback logs. Redo logs on disk or tape must be available for the entire time period spanned by the flashback logs. For example, if the flashback retention target is one week, then you must ensure that online and archived redo logs that contain all changes for the past week are accessible. Note that in practice, redo logs are typically needed much longer than the flashback retention target to support point-intime recovery.
Page 106 of 212
About the Flashback Database Window the range of SCNs for which there is currently enough flashback log data to support the FLASHBACK DATABASE command is called the flashback database window. The flashback database window cannot extend further back than the earliest SCN in the available flashback logs. Note: Some database operations, such as dropping a tablespace or shrinking a datafile, cannot be reversed with Flashback Database. In these cases the flashback database window begins at the time immediately following that operation. You cannot back up flashback logs to locations outside the flash recovery area. To increase the likelihood that enough flashback logs are retained to meet the flashback database window, you can increase the space in your flash recovery area. If the flash recovery area is not large enough to hold the flashback logs and files such as archived redo logs and other backups needed for the retention policy, then the database may delete flashback logs from the earliest SCNs to make room for other files. Consequently, the flashback database window can be shorter than the flashback retention target, depending on the size of the flash recovery area, other backups that must be retained, and how much flashback logging data is needed. The flashback retention target is a target, not a guarantee that Flashback Database will be available. If you cannot use FLASHBACK DATABASE because the flashback database window is not long enough, then you can use database point-in-time recovery (DBPITR) in most cases to achieve a similar result. Guaranteed restore points are the only way to ensure that you can use Flashback Database to return to a specific point in time or guarantee the size of the flashback window.
12.13.3 Normal Restore Points

A normal restore point assigns a restore point name to an SCN or specific point in time. Thus, a restore point functions as a bookmark or alias for this SCN. Before performing any operation that you may have to reverse, you can create a normal restore point. The control file stores the name of the restore point and the SCN.If you need to use flashback features or point-in-time recovery, then you can use the name of the restore point instead of a time or SCN. A normal restore point eliminates the need to manually record an SCN in advance or determine the correct SCN after the fact by using features such as Flashback Query. Normal restore points are lightweight. The control file can maintain a record of thousands of normal restore points with no significant impact on database performance. Normal restore points eventually age out of the control file if not manually deleted, so they require no ongoing maintenance.
12.13.4 Guaranteed Restore Points

Like a normal restore point, a guaranteed restore point serves as an alias for an SCN in recovery operations. A principal difference is that guaranteed restore points never age out of the control file and must be explicitly dropped. In general, you can use a guaranteed restore point as an alias for an SCN with any command that works with a normal restore point. Except as noted, the information about where and how to use normal restore points applies to guaranteed restore points as well. A guaranteed restore point ensures that you can use Flashback Database to rewind a database to its state at the restore point SCN, even if the generation of flashback logs is disabled. If flashback logging is enabled, then a guaranteed restore point enforces the retention of flashback logs required for Flashback Database to any SCN after the earliest guaranteed restore point. Thus, if flashback logging is enabled, you can rewind the database to any SCN in the continuum rather than to a single SCN only. Caution: If flashback logging is disabled, then you cannot use FLASHBACK DATABASE to rewind the database to SCNs between the guaranteed restore points and the current time. In this case, your only option to return the database to an intermediate SCN is DBPITR. If the recovery area has enough disk space to store the needed logs, then you can use a guaranteed restore point to rewind a whole database to a known good state days or weeks ago. As with Flashback Database, even the effects of NOLOGGING operations like direct load inserts can be reversed with guaranteed restore points.
Page 107 of 212
Note: Limitations that apply to Flashback Data base also apply to guarantee restore points. For example, shrinking a datafile or dropping a tablespace can prevent flashing back the affected datafiles to the guaranteed restore point. See the FLASHBACK DATABASE entry in Oracle Database Backup and Recovery Reference for a complete list of command prerequisites and usage notes. Guaranteed Restore Points and Storage Snapshots In practice, guaranteed restore points provide a useful alternative to storage snapshots. Storage snapshots are often used to protect a database before risky operations such as large-scale database updates or application patches or upgrades. Rather than creating a snapshot or duplicate database to test the operation, you can create a guaranteed restore point on a primary or physical standby database. You can then perform the risky operation with the certainty that the required flashback logs are retained.
12.13.5 Logging for Flashback Database and Guaranteed Restore Points

Logging for Flashback Database and guaranteed restore points involves capturing images of datafile blocks before changes are applied. The FLASHBACK DATABASE command can use these images to return the datafiles to their previous state. The chief differences between normal flashback logging and logging for guaranteed restore points are related to when blocks are logged and whether the logs can be deleted in response to space pressure in the flash recovery area. These differences affect space usage for logs and database performance. Your recoverability goals partially determine whether to enable logging for flashback database, use guaranteed restore points, or both. The implications in performance and in space usage for these features, separately and when used together, should also factor into your decision. Guaranteed Restore Points and Flash Recovery Area Space Usage the following rules govern creation, retention, overwriting and deletion of flashback logs in the flash recovery area: If the flash recovery area has enough space, then a flashback log is created whenever necessary to satisfy the flashback retention target. If a flashback log is old enough that it is no longer needed to satisfy the flashback retention target, then a flashback log can be reused. If the database needs to create a new flashback log and the flash recovery area is full or there is no disk space, then the oldest flashback log is reused instead. Note: Reusing the oldest flashback log shortens the flashback database window. If enough flashback logs are reused due to a lack of disk space, then the flashback retention target may not be satisfied. If the flash recovery area is full, then an archived redo log may be automatically deleted by the flash recovery area to make space for other files. In such a case, any flashback logs that would require the use of that redo log file for the use of FLASHBACK DATABASE are also deleted. When you create a guaranteed restore point, with or without enabling full flashback database logging, you must monitor the space available in your flash recovery area. No file in the flash recovery area is eligible for deletion if it is required to satisfy the guarantee. Thus, retention of flashback logs and other files required to satisfy the guarantee, in addition to files required to satisfy the backup retention policy, can cause the flash recovery area to fill completely. Caution: If no files are eligible for deletion from the flash recovery area because of the requirements imposed by your retention policy and the guaranteed restore point, then the database behaves as if it has encountered a disk full condition. In many circumstances, this causes your database to halt. Logging for Guaranteed Restore Points with Flashback Logging Disabled Assume that you create a guaranteed restore point when logging for Flashback Database is disabled. In this case, the first time a datafile block is modified after the time of the guaranteed restore point, the database stores an image of the block before the modification in the flashback logs. Thus, the flashback logs preserve the contents of every changed data block at the time that the guaranteed restore point was created. Later modifications to the same block do not because the contents to be logged again unless another guaranteed restore point was created after the block was last modified. This method of logging has the following important consequences: FLASHBACK DATABASE can re-create the datafile contents at the time of a guaranteed restore point by
Configuring the RMAN Environment means of the block images.
Page 108 of 212
Disk space usage is considerably less than normal flashback logging. Less space is needed because each changed block is only logged once. Thus, you can maintain a guaranteed restore point for days or even weeks without concern over the growth of flashback logs. Typically, the performance overhead of logging for a guaranteed restore point without flashback database logging is lower as well.
Assume that your primary goal is the ability to return your database to the time at which the guaranteed restore point was created. In this case, it is usually more efficient to turn off flashback logging and use only guaranteed restore points. For example, suppose that you are performing an application upgrade on a database host over a weekend. You could create a guaranteed restore point at the start of the upgrade. If the upgrade fails, then reverse the changes with FLASHBACK DATABASE.
Logging for Flashback Database with Guaranteed Restore Points Defined If you enable Flashback Database and define one or more guaranteed restore points, then the database performs normal flashback logging. In this case, the recovery area retains the flashback logs required to flash back to any arbitrary time between the present and the earliest currently defined guaranteed restore point. Flashback logs are not deleted in response to space pressure if they are required to satisfy the guarantee. Flashback logging causes some performance overhead. Depending upon the pattern of activity on your database, it can also cause significant space pressure in the flash recovery area. Thus, you should monitor space used in the flash recovery area.
12.13.6 Prerequisites for Flashback Database and Guaranteed Restore Points

The prerequisites for enabling Flashback Database are the following: Your database must be running in ARCHIVELOG mode, because archived logs are used in the Flashback Database operation. You must have a flash recovery area enabled, because flashback logs can only be stored in the flash recovery area. For Real Application Clusters databases, the flash recovery area must be stored in a clustered file system or in ASM. To support the use of guaranteed restore points, the database must satisfy the following prerequisites: The COMPATIBLE initialization parameter must be set to 10.2 or greater. The database must be running in ARCHIVELOG mode. To rewind your database to a guaranteed restore point, the FLASHBACK DATABASE command requires the use of archived redo logs starting from around the time of the restore point. A flash recovery area must be configured, Guaranteed restore points use a mechanism similar to flashback logging. As with flashback logging, Oracle Database must store the required logs in the flash recovery area. If Flashback Database is not enabled, then the database must be mounted, not open, when creating the first guaranteed restore point (or if all previously created guaranteed restore points have been dropped). Note: No special requirements exist for using normal restore points.
Page 109 of 212
12.13.7 Enabling Flashback Database

To enable logging for Flashback Database, set the DB_FLASHBACK_RETENTION_TARGET initialization parameter and issue the ALTER DATABASE FLASHBACK ON statement. To enable flashback logging: 1. Start SQL*Plus and ensure that the database is mounted, but not open. For example: SHUTDOWN IMMEDIATE; STARTUP MOUNT; 2. Optionally, set the DB_FLASHBACK_RETENTION_TARGET to the length of the desired flashback window in minutes: ALTER SYSTEM SET DB_FLASHBACK_RETENTION_TARGET=4320; # 3 days By default DB_FLASHBACK_RETENTION_TARGET is set to one day (1440 minutes). 3. Enable the Flashback Database feature for the whole database: ALTER DATABASE FLASHBACK ON; 4. Optionally, disable flashback logging for specific tablespaces. By default, flashback logs are generated for all permanent tablespaces. If you wish, you can reduce overhead by disabling flashback logging for specific tablespaces as in the following example: ALTER TABLESPACE tbs_3 FLASHBACK OFF; You can re-enable flashback logging for a tablespace later with this command: ALTER TABLESPACE tbs_3 FLASHBACK ON; Note that if you disable Flashback Database for a tablespace, then you must take its datafiles offline before running FLASHBACK DATABASE. You can disable flashback logging for the entire database with this command: ALTER DATABASE FLASHBACK OFF; Enabling Flashback Database on a physical standby database enables you to flash back a standby database. Flashback Database of standby databases has a number of applications in the Data Guard environment.
12.13.8 Creating Normal and Guaranteed Restore Points

To create normal or guaranteed restore points, use the CREATE RESTORE POINT SQL statement, providing a name for the restore point and specifying whether it is to be a guaranteed restore point or a normal one (the default). To create a restore point: 1. Connect SQL*Plus to a target database. 2. Ensure that the database is open or mounted. If the database is mounted, then it must have been shut down cleanly (unless it is a physical standby database). 3. Run the CREATE RESTORE POINT statement. The following example shows how to create a normal restore point in SQL*Plus: SQL> CREATE RESTORE POINT before_upgrade; This example shows how to create a guaranteed restore point: SQL> CREATE RESTORE POINT before_upgrade GUARANTEE FLASHBACK DATABASE;
12.13.9 Configuring Performance
the
Environment
for Optimal
Flashback
Database
Maintaining flashback logs imposes comparatively limited overhead on an Oracle database instance. Changed blocks are written from memory to the flashback logs at relatively infrequent, regular intervals, to limit processing and I/O overhead. To achieve good performance for large production databases with Flashback Database enabled, Oracle recommends the following: Use a fast file system for your flash recovery area, preferably without operating system file caching. Files that the database creates in the flash recovery area, including flashback logs, are typically large. Operating system file
Page 110 of 212
caching is typically not effective for these files, and may actually add CPU overhead for reading from and writing to these files. Thus, it is recommended to use a file system that avoids operating system file caching, such as ASM. Configure enough disk spindles for the file system that will hold the flash recovery area. For large production databases, multiple disk spindles may be needed to support the required disk throughput for the database to write the flashback logs effectively. If the storage system used to hold the flash recovery area does not have nonvolatile RAM, then try to configure the file system on striped storage volumes. Use a relatively small stripe size such as 128 KB. This technique enables each write to the flashback logs to be spread across multiple spindles, improving performance. For large databases, set the initialization parameter LOG_BUFFER to at least 8 MB. This setting ensures that the database allocates maximum memory (typically 16MB) for writing flashback database logs. The overhead of logging for Flashback Database depends on the mixture of reads and writes in the database workload. The more writeintensive the workload, the higher the overhead caused by turning on logging for Flashback Database. Queries do not change data and thus do not contribute to logging activity for Flashback Database.
RMAN Bakup Concepts
Page 111 of 212
13. RMAN Backup Concepts

13.1 Consistent and Inconsistent RMAN Backups
The RMAN command for making backups is BACKUP. The RMAN BACKUP command supports backing up the following types of files: Datafiles and control files Server parameter file Archived redo logs RMAN backups
Although the database depends on other types of files, such as network configuration files, password files, and the contents of the Oracle home, you cannot back up these files with RMAN. Likewise, some features of Oracle, such as external tables, may depend upon files other than the datafiles, control files, and redo log. RMAN cannot back up these files. Use some non-RMAN backup solution for any files not in the preceding list. When you execute the BACKUP command in RMAN, the output is always either one or more backup sets or one or more image copies. A backup set is an RMAN-specific proprietary format, whereas an image copy is a bit-for-bit copy of a file. By default, RMAN creates backup sets.
13.1.1 Consistent Backups

You can use the BACKUP command to make consistent and inconsistent backups of the database. A consistent backup occurs when the database is in a consistent state. A database is in a consistent state after being shut down with the SHUTDOWN NORMAL, SHUTDOWN IMMEDIATE, or SHUTDOWN TRANSACTIONAL commands. A consistent shutdown guarantees that all redo has been applied to the datafiles. If you mount the database and take a backup a t this point, then you can restore the database backup later and open it without performing media recovery.
13.1.2 Inconsistent Backups

Any database backup of that is not consistent is an inconsistent backup. A backup made when the database is open is inconsistent, as is a backup made after an instance failure or SHUTDOWN ABORT command. When a database is restored from an inconsistent backup, Oracle must perform media recovery before the database can be opened, applying any pending changes from the redo logs. Note: RMAN does not permit you to make inconsistent backups when the database is in NOARCHIVELOG mode. If you employ user-managed backup techniques for a NOARCHIVELOG database, then you must not make inconsistent backups of this database. As long as the database runs in ARCHIVELOG mode, and you back up the archived redo logs and datafiles, inconsistent backups can be the foundation for a sound backup and recovery strategy. Inconsistent backups offer superior availability because you do not have to shut down the database to make backups that fully protect the database.
13.2 Online Backups and Backup Mode

When performing a user-managed backup of an online tablespace or database, an operating system utility such as cp or dd may read a block at the same time that database writer is updating a block. In this case, the block copied to the backup media may have been updated in its first half, while the second half contains older data. This type of logical corruption is known as a fractured block, that is, a block that is not consistent with respect to an SCN. If this backup needs to be restored later, and if the block requires recovery, then recovery will fail because the block is not usable.
RMAN Bakup Concepts
Page 112 of 212
When performing a user-managed online backup, you must place your datafiles into backup mode with the ALTER DATABASE or ALTER TABLESPACE statement with the BEGIN BACKUP clause. When a tablespace is in backup mode, the database writes the before image for an entire block to the redo stream before modifying a block. The database also records changes to the block in the online redo log. Backup mode also freezes the datafile checkpoint until the file is removed from backup mode. Oracle Database performs this safeguard because it cannot guarantee that a third-party backup tool will copy the file header before copying the data blocks. Unlike user-managed tools, RMAN does not require extra logging or backup mode because it knows the format of data blocks. RMAN is guaranteed not to back up fractured blocks. During an RMAN backup, a database server session reads each data block and checks whether it is fractured by comparing the block header and footer. If a block is fractured, then the session rereads the block. If the same fracture is found, then the block is considered permanently corrupt. Also, RMAN does not need to freeze the datafile header checkpoint because it knows the order in which the blocks will be read, which enables it to capture a known good checkpoint for the file.
13.3 Backup Sets

When you execute the BACKUP command in RMAN, you create one or more backup sets or image copies. By default, RMAN creates backup sets regardless of whether the destination is disk or a media manager.
13.3.1 Backup Sets and Backup Pieces

RMAN can store backup data in a logical structure called a backup set, which is the smallest unit of an RMAN backup. A backup set contains the data from one or more datafiles, archived redo logs, or control files or server parameter file. Backup sets, which are only created and accessed through RMAN, are the only form in which RMAN can write backups to media managers such as tape drives and tape libraries. A backup set contains one or more binary files in an RMAN-specific format. This file is known as a backup piece. A backup set can contain multiple datafiles. For example, you can back up ten datafiles into a single backup set consisting of a single backup piece. In this case, RMAN creates one backup piece as output. The backup set contains only this backup piece. If you specify the SECTION SIZE parameter on the BACKUP command, then RMAN produces a multisection backup. This is a backup of a single large file, produced by multiple channels in parallel, each of which produces one backup piece. Each backup piece contains one file section of the file being backed up. RMAN only records backup sets in the repository that complete successfully. There is no such thing as a partial backup set.
13.3.2 Compression for Backup Sets

When backing up datafiles to backup sets, RMAN can use unused block compression to skip datafile blocks. RMAN always skips blocks that have never been used. Thus, datafile backup sets are typically smaller than datafile copies and take less time to write. Unused block compression is fundamental to how RMAN writes datafiles into backup pieces and cannot be disabled. RMAN also supports binary compression of backup sets. The supported algorithms are BZIP2 (default) and ZLIB. The BZIP2 algorithm is optimized for maximum compression, whereas the ZLIB algorithm is optimized for CPU efficiency. BZIP2 consumes more CPU resource than ZLIB, but will usually produce more compact backups. The COMPATIBLE initialization parameter must be set to 11.0.0 or higher for ZLIB compression, which requires the Oracle Advanced Compression option. RMAN compresses the backup set contents before writing them to disk. No extra uncompression steps are required during recovery when you use RMAN compression. In backup undo optimization, RMAN excludes undo not needed for recovery of a backup, that is, for transactions have already been committed. You can enable and disable backup optimization, but backup undo optimization is built-in behavior.
13.3.3 Encryption for Backup Sets

RMAN supports backup encryption for backup sets. You can use wallet-based transparent encryption, passwordbased encryption, or both. You can use the CONFIGURE ENCRYPTION command to configure persistent transparent encryption. Use the SET ENCRYPTION, command at the RMAN session level to specify passwordbased encryption.
RMAN Bakup Concepts
Page 113 of 212
Note: Wallet-based encryption is more secure than password-based encryption because no passwords are involved. You should use password-based encryption only when absolutely necessary because your backups need to be transportable. To create encrypted backups on disk with RMAN, the database must use the Advanced Security Option. The Oracle Secure Backup SBT is the only supported interface for making encrypted RMAN backups directly to tape. Note that the Advanced Security Option is not required when making encrypted backups to the Oracle Secure Backup SBT.
13.3.4 Filenames for Backup Pieces

You can either let RMAN determine a unique name for backup pieces or use the FORMAT clause to specify a name. If you do not specify the FORMAT parameter, then RMAN automatically generates a unique filename with the %U substitution variable in the default backup location. An example of an SBT backup piece name generated by %U is 12i1nk47_1_1. An example of a backup piece on disk is as follows: /d1/orcva/TEST/backupset/2007_12_12/o1_mf_nnndf_TAG20071212T162825_2qyl99jm_.bkp The FORMAT clause supports substitution variables other than %U for generating unique filenames. For example, you can use %d to generate the name of the database, %I for the DBID, %t for the timestamp, and so on. You can specify up to four FORMAT parameters. If you specify multiple FORMAT parameters, then RMAN uses the multiple FORMAT parameters only when you specify multiple copies. You can create multiple copies by using the BACKUP ... COPIES, SET BACKUP COPIES, or CONFIGURE ... BACKUP COPIES commands.
13.3.5 Number and Size of Backup Pieces

By default a backup set contains one backup piece. To restrict the size of each backup piece, specify the MAXPIECESIZE option of the CONFIGURE CHANNEL or ALLOCATE CHANNEL commands. This option limits backup piece size to the specified number of bytes. If the total size of the backup set is greater than the specified backup piece size, then RMAN creates multiple physical pieces to hold the backup set contents. You can use this option for media managers that cannot manage a backup piece that spans more than one tape. For example, if a tape can hold 10 GB, but the backup set being created must hold 80 GB of data, then you must instruct RMAN to create backup pieces of 10 GB, small enough to fit on the tapes used with the media manager. In this case, the backup set media will consist of eight tapes. Media managers supporting SBT 2.0 can return a value to RMAN indicating the largest supported backup piece size, which RMAN will use in planning backup activities. Note that if you specify the SECTION SIZE parameter on the BACKUP command, then RMAN can create a multisection backup. In this case, a single backup set can contain multiple backup pieces, each containing a file section. The purpose of multisection backups is to enable multiple channels to back up a large file in parallel.
13.3.6 Number and Size of Backup Sets

You use the backupSpec clause of the BACKUP command to specify the objects to be backed up. Each backupSpec clause produces at least one backup set. The total number and size of backup sets depends for the most part on an internal RMAN algorithm. However, you can influence RMAN behavior with the MAXSETSIZE parameter in the CONFIGURE or BACKUP command. By limiting the size of the backup set, the parameter indirectly limits the number of files in the set and can possibly force RMAN to create additional backup sets. Also, you can specify BACKUP ... FILESPERSET to specify the maximum number of files in each backup set.
13.3.7 Multiplexed Backup Sets

When creating backup sets, RMAN can simultaneously read multiple files from disk and then write their blocks into the same backup set. For example, RMAN can read from two datafiles simultaneously, and then combine the blocks from these datafiles into a single backup piece. The combination of blocks from multiple files is called backup multiplexing. Image copies, by contrast, are never multiplexed. Note: If RMAN creates a multisection backup of a datafile, then the datafile will not be multiplexed with any other datafile or file section.
RMAN Bakup Concepts
Page 114 of 212
As Figure illustrates, RMAN can back up three datafiles into a backup set that contains only one backup piece. This backup piece contains the intermingled data blocks of the three input datafiles. Figure - Datafile Multiplexing
RMAN multiplexing is determined by several factors. For example, the FILESPERSET parameter of the BACKUP command determines how many datafiles to put in each backup set. The MAXOPENFILES parameter of ALLOCATE CHANNEL or CONFIGURE CHANNEL defines how many datafiles RMAN can read from simultaneously. The basic multiplexing algorithm is as follows: Number of files in each backup set This number is the minimum of the FILESPERSET setting and the number of files read by each channel. The FILESPERSET default is 64. The level of multiplexing This is the number of input files simultaneously read and then written into the same backup piece. The level of multiplexing is the minimum of MAXOPENFILES and the number of files in each backup set. The MAXOPENFILES default is 8.Suppose that you back up 12 datafiles with one channel. The number of files in each backup set is 4. The level of multiplexing is the lesser of this number and 8. Thus, the channel simultaneously writes blocks from 4 datafiles into each backup piece. Now suppose that you back up 50 datafiles with one channel. The number of files in each backup set is 50. The level of multiplexing is the lesser of this number and 8. Thus, the channel simultaneously writes blocks from 8 datafiles into each backup piece. RMAN multiplexing of backup sets is different from media manager multiplexing. One type of media manager multiplexing occurs when the media manager writes the concurrent output from multiple RMAN channels to a single sequential device. Another type occurs when a backup mixes database files and non-database files on the same tape. Caution: Oracle recommends that you never use media management multiplexing for RMAN backups.
13.3.8 Proxy Copies

During a proxy copy, RMAN turns over control of the data transfer to a media manager that supports this feature. Proxy copy can only be used with media managers that support it and cannot be used with channels of type DISK.
RMAN Bakup Concepts
Page 115 of 212
The PROXY option of the BACKUP command specifies that a backup should be a proxy copy. For each file that you attempt to back up with the BACKUP PROXY command, RMAN queries the media manager to determine whether it can perform a proxy copy. If the media manager cannot proxy copy the file, then RMAN backs the file up as if the PROXY option had not been used. (Use the PROXY ONLY option to force RMAN to fail if a proxy copy cannot be performed.) Note that control files are never backed up with proxy copy. If the PROXY option is specified on an operation backing up a control file, then it is silently ignored for the purposes of backing up the control file.
13.4 Image Copies

An image copy is an exact copy of a single datafile, archived redo log file, or control file. Image copies are not stored in an RMAN-specific format. They are identical to the results of copying a file with operating system commands. RMAN can use image copies during RMAN restore and recover operations, and you can also use image copies with non-RMAN restore and recovery techniques.
13.4.1 RMAN-Created Image Copies

To create image copies and have them recorded in the RMAN repository, you run the RMAN BACKUP AS COPY command. Alternatively, you can configure the default backup type for disk as image copies. A database server session is used to create the copy. The server session also performs actions such as validating the blocks in the file and recording the image copy in the RMAN repository. As with backup pieces, FORMAT variables are also used to specify the names of image copies. The default format %U, is defined differently for image copies. The following example shows name for datafile 2 generated by %U: /d1/oracle/work/orcva/RDBMS/datafile/o1_mf_sysaux_2qylngm3_.dbf When creating image copies, you can also name the output copies with the DB_FILE_NAME_CONVERT parameter of the BACKUP command. This parameter works identically to the DB_FILE_NAME_CONVERT initialization parameter. Pairs of filename prefixes are provided to change the names of the output files. If a file is not converted by any of the pairs, then RMAN uses the FORMAT specification; if no FORMAT is specified, then RMAN uses the default format %U. Example copies the datafiles whose filename is prefixed with /maindisk/oradata/users so that they are prefixed with /backups/users_ts. Example Specifying Filenames with DB_FILE_NAME_CONVERT BACKUP AS COPY TABLESPACE users DB_FILE_NAME_CONVERT ('/maindisk/oradata/users', '/backups/users_ts'); If you run a RESTORE command, then by default RMAN restores a datafile or control file to its original location by copying an image copy backup to that location. Image copies are chosen over backup sets because of the extra overhead of reading through an entire backup set in search of files to be restored. If you need to restore and recover a current datafile, and if you have an image copy available on disk, then you do not need to have RMAN copy the image copy back to its old location. Instead, you can use the image copy in place as a replacement for the datafile to be restored.
13.4.2 User-Managed Image Copies

RMAN can use image copies created by mechanisms outside of RMAN, such as native operating system file copy commands or third-party utilities that leave image copies of files on disk. This type of copy is known as a usermanaged backup or operating system backup. You can use the CATALOG command to inspect an existing image copy and enter its metadata into the RMAN repository. However, the CATALOG command does not do the following:
RMAN Bakup Concepts Read all blocks in the datafile copy to insure there are no corruptions Guarantee that the image copy was correctly made in backup mode
Page 116 of 212
After you catalog these files, you can use them with the RESTORE or SWITCH commands just as you can for RMAN-generated image copies. Some sites store their datafiles on mirrored disk volumes, which permit the creation of image copies by breaking a mirror. After you have broken the mirror, you can notify RMAN of the existence of a new user-managed copy, thus making it eligible for a backup. You must notify RMAN when the copy is no longer available by using the CHANGE ... UNCATALOG command.
13.5 Multiple Copies of RMAN Backups

In RMAN, you can make multiple, identical copies of backups in the following ways: Duplex backups with the BACKUP ... COPIES command, in which case RMAN creates more than one copy of each backup set Back up your files as backup sets or image copies, and then back up the backup sets or image copies with the RMAN BACKUP BACKUPSET or BACKUP COPY OF commands
13.5.1 Duplexed Backup Sets

When backing up datafiles, archived redo log files, server parameter files, and control files into backup pieces, RMAN can create a duplexed backup set, producing up to four identical copies of each backup piece in the backup set on different backup destinations with one BACKUP command. Duplexing is not supported for backup operations that produce image copies. You can use the COPIES parameter in the CONFIGURE, SET, or BACKUP commands to specify duplexing of backup sets when using the BACKUP command. RMAN can duplex backups to either disk or tape, but cannot duplex backups to tape and disk simultaneously. When backing up to tape, ensure that the number of copies does not exceed the number of available tape devices. The FORMAT parameter of the BACKUP command specifies the destinations for duplexed backups. The following example creates 3 copies of the backup of datafile 7: BACKUP DEVICE TYPE DISK COPIES 3 DATAFILE 7 FORMAT '/disk1/%U','?/oradata/%U','?/%U'; RMAN places the first copy of each backup piece in /disk1, the second in ?/oradata, and the third in the Oracle home. Note that RMAN does not produce 3 backup sets, each with a different unique backup set key. Rather, RMAN produces one backup set with a unique key, and generates 3 identical copies of each backup piece in the set.
13.6 Backups of Backups

You can use the BACKUP command to back up existing backup sets and image copies.
13.6.1 Backups of Backup Sets

The RMAN BACKUP BACKUPSET command backs up backup sets that were created on disk. The command is a useful way to spread backup s among multiple media. If RMAN discovers that one copy of a backup set is corrupted or missing, then it searches for other copies of the same backup set. This behavior is similar to the behavior of RMAN when backing up archived redo logs that exist in multiple archiving destinations. Example shows how you might run the BACKUP command weekly as part of the production backup schedule. In this way, you ensure that all your backups exist on both disk and tape.Example Backing Up Backup Sets to Tape: BACKUP DEVICE TYPE DISK AS BACKUPSET DATABASE PLUS ARCHIVELOG; BACKUP DEVICE TYPE sbt BACKUPSET ALL; # copies backup sets on disk to tape Note: Backups to sbt that use automatic channels require that you first run the CONFIGURE DEVICE TYPE sbt command.
RMAN Bakup Concepts
Page 117 of 212
You can also use BACKUP BACKUPSET to manage backup space allocation. Example backs up backup sets that were created more than a week ago from disk to tape, and then deletes them from disk. Example Managing Space Allocation: BACKUP DEVICE TYPE sbt BACKUPSET COMPLETED BEFORE 'SYSDATE-7' DELETE INPUT; Note that DELETE INPUT here is equivalent to DELETE ALL INPUT: RMAN deletes all existing copies of the backup set. If you duplexed a backup to four locations, then RMAN deletes all four copies of the pieces in the backup set.
13.6.2 Backups of Image Copies

You can use the BACKUP COPY OF command to back up existing image copies of database files either as backup sets or as image copies. When using this command, an image copy of every datafile specified in the command must already exist. If there are multiple copies of a datafile, then the latest one is used. If you specify a tablespace or the whole database, then RMAN issues an error if there are data files in the database or tablespace for which there are no image copy backups.
13.7 Control File and Server Parameter File Autobackups

Having recent backups of your control file and server parameter file is extremely valuable in many recovery situations. To increase the likelihood that you will have such backups, the database supports control file and server parameter file autobackups. The autobackup occurs independently of any backup of the current control file explicitly requested as part of your BACKUP command. With a control file autobackup, RMAN can recover the database even if the current control file, recovery catalog, and server parameter file are inaccessible. Because the path used to store the autobackup follows a well-known format, RMAN can search for and restore the server parameter file from that autobackup. After you have started the instance with the restored server parameter file, RMAN can restore the control file from the autobackup. After you mount the control file, use the RMAN repository in the mounted control file to restore the datafiles.
13.7.1 When RMAN Performs Control File Autobackups

If CONFIGURE CONTROLFILE AUTOBACKUP is ON, then RMAN automatically backs up the control file and the current server parameter file (if used to start up the database) at the end of a successful BACKUP command. If the database runs in ARCHIVELOG mode, RMAN makes control file autobackups when a structural change to the database affects the contents of the control file.
13.7.2 How RMAN Performs Control File Autobackups

The first channel allocated during the backup job creates the autobackup and places it into its own backup set. For autobackups after database structural changes, the server process associated with the structural change makes the backup.If a server parameter file is in use by the database, and then RMAN backs it up in the same backup set as the control file autobackup. After the autobackup completes, the database writes a message containing the complete path of the backup piece and the device type to the alert log located in the Automatic Diagnostic Repository (ADR). Note: Control file autobackups are never duplexed. The control file autobackup filename has a default format of %F for all device types, so that RMAN can determine the file location and restore it without a repository. You can specify a different format with the CONFIGURE CONTROLFILE AUTOBACKUP FORMAT command, but all autobackup formats must include the %F variable. If you do not use the default format, then during disaster recovery you must specify the format that was used to generate the autobackups. Otherwise, RMAN cannot restore the autobackup.
RMAN Bakup Concepts
Page 118 of 212
13.8 Incremental Backups

By default, RMAN makes full backups. A full backup of a datafile includes every allocated block in the file being backed up. A full backup of a datafile can be an image copy, in which case every data block is backed up. It can also be stored in a backup set, in which case datafile blocks not in use may be skipped. A full backup is the default type of RMAN backup. A full backup has no effect on subsequent incremental backups and is not considered a part of an incremental backup strategy. Image copies are always full backups because they include every data block in a datafile. A backup set is by default a full backup because it can potentially include every data block in a datafile, although unused block compression means that blocks never used are excluded and, in some cases, currently unused blocks are excluded. In contrast to a full backup, incremental backup copies only those data blocks that have changed since a previous backup. You can use RMAN to create incremental backups of datafiles, tablespaces, or the whole database. A full backup cannot be part of an incremental backup strategy; that is, it cannot be the parent for a subsequent incremental backup.
13.8.1 Multilevel Incremental Backups

RMAN can create multilevel incremental backups. Each incremental level is denoted by a value of 0 or 1. A level 0 incremental backup, which is the base for subsequent incremental backups, copies all blocks containing data. You can create a level 0 database backup as backup sets or image copies. The only difference between a level 0 incremental backup and a full backup is that a full backup is never included in an incremental strategy. Thus, a full backup is the parent of incremental backups whose level is greater than 0. A level 1 incremental backup can be either of the following types: A differential incremental backup, which backs up all blocks changed after the most recent incremental backup at level 1 or 0 A cumulative incremental backup, which backs up all blocks changed after the most recent incremental backup at level 0 Incremental backups are differential by default. Note: Cumulative backups are preferable to differential backups when recovery time is more important than disk space, because fewer incremental backups need to be applied during recovery. The size of the backup file depends solely upon the number of blocks modified, the incremental backup level, and the type of incremental (differential or cumulative).
13.8.2 Differential Incremental Backups

In a differential level 1 backup, RMAN backs up all blocks that have changed since the most recent incremental backup at level 1 (cumulative or differential) or level 0. For example, in a differential level 1 backup, RMAN determines which level 1 backup occurred most recently and backs up all blocks modified after that backup. If no level 1 is available, then RMAN copies all blocks changed since the base level 0 backup. If no level 0 backup is available in the current or parent incarnation, then the behavior varies with the compatibility mode setting. If compatibility is >=10.0.0, RMAN copies all blocks that have been changed since the file was created. Otherwise, RMAN behaves as it did in previous releases, by generating a level 0 backup.
RMAN Bakup Concepts
Page 119 of 212
13.8.3 Cumulative Incremental Backups

In a cumulative level 1 backup, RMAN backs up all blocks used since the most recent level 0 incremental backup in either the current or parent incarnation. Cumulative incremental backups reduce the work needed for a restore by ensuring that you only need one incremental backup from any particular level. Cumulative backups require more space and time than differential backups because they duplicate the work done by previous backups at the same level.
13.9 Block Change Tracking

The block change tracking feature for incremental backups improves incremental backup performance by recording changed blocks in each datafile in a block change tracking file. This file is a small binary file stored in the database area. RMAN tracks changed blocks as redo is generated. If you enable block change tracking, then RMAN uses the change tracking file to identify changed blocks for an incremental backup, thus avoiding the need to scan every block in the datafile. RMAN only uses block change tracking when the incremental level is greater than 0 because a level 0 incremental backup includes all blocks.
13.10 Incremental Backup Algorithm

The following concepts are essential for understanding the algorithm that RMAN uses to make incremental backups: Checkpoint SCN
RMAN Bakup Concepts
Page 120 of 212
Every datafile has a datafile checkpoint SCN, which you can view in V$DATAFILE.CHECKPOINT_CHANGE#. All changes with an SCN lower than this SCN are guaranteed to be in the file. When a level 0 incremental backup is restored, the restored datafile contains the checkpoint SCN that it had when the level 0 was created. When a level 1 incremental is applied to a file, the checkpoint SCN of the file is advanced to the checkpoint SCN that the file had when the incremental level 1 was created. Incremental start SCN This SCN applies only to level 1 incremental backups. All blocks whose SCN is greater than or equal to the incremental start SCN are included in the backup. Blocks whose SCN is lower than the incremental start SCN are not included in the backup. The incremental start SCN is most often the checkpoint SCN of the parent of the level 1 backup. Block SCN Every data block in a datafile records the SCN at which the most recent change was made to the block. When RMAN makes an incremental backup of a file, RMAN reads the file, examines the SCN of every block, and backs up blocks whose SCN is greater than or equal to the incremental start SCN for this backup. If the backup is differential, then the incremental start SCN is the checkpoint SCN of the most recent level 1 backup. If the backup is cumulative, then the incremental start SCN is the checkpoint SCN of the most recent level 0 backup. When block change tracking is enabled, RMAN uses bitmaps to avoid reading blocks that have not changed during the range from incremental start SCN to checkpoint SCN. Note that RMAN still examines every block that is read and uses the SCN in the block to decide which blocks to include in the backup. One consequence of the incremental backup algorithm is that RMAN applies all blocks containing changed data during recovery, even if the change is to an object created with the NOLOGGING option. Thus, if you restore a backup made before NOLOGGING changes were made, then incremental backups are the only way to recover them.
13.11 Recovery with Incremental Backups

During media recovery, RMAN examines the restored files to determine whether it can recover them with an incremental backup. If it has a choice, then RMAN always chooses incremental backups over archived redo logs because applying changes at a block level is faster than applying redo. RMAN does not need to restore a base incremental backup of a datafile to apply incremental backups to the datafile during recovery. For example, you can restore datafile image copies and recover them with incremental backups.
13.12 Backup Retention Policies

You can use the CONFIGURE RETENTION POLICY command to create a persistent and automatic backup retention policy. When a backup retention policy is in effect, RMAN considers a backup of datafiles or control files as an obsolete backup, that is, no longer needed for recovery, according to criteria specified in the CONFIGURE command. You can use the REPORT OBSOLETE command to view obsolete files and the DELETE OBSOLETE command to delete them. As you produce backups over time, older backups become obsolete as they are no longer needed to satisfy the retention policy. RMAN can identify the obsolete files for you, but it does not automatically delete them. You must use the DELETE OBSOLETE command to delete files that are no longer needed to satisfy the retention policy. If a flash recovery area is configured, then the database automatically deletes files that are either obsolete or already backed up to tape when more recovery area space is needed for new files. The disk quota rules are distinct from the retention policy rules, but the database will never delete files in violation of the retention policy to satisfy the disk quota. A backup is obsolete when REPORT OBSOLETE or DELETE OBSOLETE determines, based on the user-defined retention policy, that it is not needed for recovery. A backup is considered an expired backup only when RMAN
RMAN Bakup Concepts
Page 121 of 212
performs a crosscheck and cannot find the file. In short, obsolete means a file is not needed, whereas expired means it is not found. A backup retention policy applies only to full or level 0 datafile and control file backups. For datafile copies and proxy copies, if RMAN determines that the copy or proxy copy is not needed, then the copy or proxy copy can be deleted. For datafile backup sets, RMAN cannot delete the backup set until all datafile backups within the backup set are obsolete. The retention policy does not directly affect archived redo logs and incremental level 1 backups. Rather, these files become obsolete when no full backups exist that need them. Besides affecting full or level 0 datafile and control file backups, the retention policy affects archived redo logs and level 1 incremental backups. First, RMAN decides which datafile and control file backups are obsolete. Then, RMAN considers as obsolete all archived logs and incremental level 1 backups that are not needed to recover the oldest datafile or control file backup that must be retained. Note: RMAN cannot implement an automatic retention policy if backups are deleted by non-RMAN techniques, for example, through the media manager's tape retention policy. The media manager should never expire a tape until all RMAN backups on that tape have been removed from the media manager's catalog.
13.12.1 Recovery Window

A recovery window is a period of time that begins with the current time and extends backward in time to the point of recoverability. The point of recoverability is the earliest time for a hypothetical point-in-time recovery, that is, the earliest point to which you can recover following a media failure. For example, if you implement a recovery window of one week, then RMAN retains full backups and required incremental backups and archived logs so that the database can be recovered up to 7 days in the past. You implement this retention policy as follows: CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; This command ensures that for each datafile one backup that is older than the point of recoverability must be retained. For example, if the recovery window is 7, then there must always exist one backup of each datafile that satisfies the following condition: SYSDATE - BACKUP CHECKPOINT TIME >= 7 All backups older than the most recent backup that satisfied this condition are obsolete. Assume the following retention policy illustrated in Figure. The retention policy has the following aspects: The recovery window is 7 days. Database backups are scheduled every two weeks on these days: January 1 January 15 January 29 February 12
The database runs in ARCHIVELOG mode, and archived logs are saved on disk only as long as needed for the retention policy. In this scenario, the current time is January 30 and the point of recoverability is January 23. Note how the January 14 backup is not obsolete even though a more recent backup (January 28) exists in the recovery window. This situation occurs because restoring the January 28 backup does not enable you to recover to the earliest time in the window, January 23. To ensure recoverability to any point in the window, you must save the January 14 backup and all archived logs from sequence 500 to 1150.
13.12.2 Backup Redundancy

In some cases using a recovery window can complicate disk space planning because the number of backups that must be retained is not constant and depends on the backup schedule. In contrast, a redundancy-based retention
RMAN Bakup Concepts
Page 122 of 212
policy specifies how many backups of each datafile must be retained. For example, you can configure a redundancy of 2 as follows: CONFIGURE RETENTION POLICY TO REDUNDANCY 2; The default retention policy is configured to REDUNDANCY 1.
13.12.3 Batch Deletes of Obsolete Backups

You can run the REPORT OBSOLETE command to determine which backups are currently obsolete according to the retention policy. A companion command, DELETE OBSOLETE, deletes all files which are obsolete according to the retention policy. You can run DELETE OBSOLETE periodically to minimize space wasted by storing obsolete backups. For example, you can run DELETE OBSOLETE in a weekly script. You can also override the configured retention policy the configured retention policy by specifying the REDUNDANCY or RECOVERY WINDOW options on the REPORT or DELETE commands. Note that using DELETE OBSOLETE with a recovery window shorter than the configured recovery window effectively reduces the window of recoverability. For example, if the configured window is 14 days, but you execute DELETE OBSOLETE RECOVERY WINDOW OF 7 DAYS, then you will no longer be able to recover to a time between 7 and 14 days ago.
13.13 Backup Retention Policy and Flash Recovery Area Deletion Rules
The RMAN status OBSOLETE is always determined in reference to a retention policy. For example, if a database backup is considered OBSOLETE in the RMAN repository, it is because it is either not needed for recovery to a point within the recovery window, or it is redundant. If you configure a flash recovery area, then the database uses an internal algorithm to select files in the flash recovery area that are no longer needed to meet the configured retention policy. These backups have status OBSOLETE and are eligible for deletion to satisfy the disk quota rules. The retention policy is never violated when determining which files to delete from the flash recovery area to satisfy the disk quota rules.There is one important difference between the flash recovery area rules for OBSOLETE status and the disk quota rules for deletion eligibility. Assume that archived logs 1000 through 2000, which are on disk, are needed for the current recovery window and so are not obsolete. If you back up these logs to tape, then the retention policy considers the disk logs as required, that is, not obsolete. Nevertheless, the flash recovery area disk quota algorithm considers the logs on disk as eligible for deletion because they have been backed up to tape. The logs on disk do not have OBSOLETE status in the repository, but they are eligible for deletion by the flash recovery area.
Backingup the Database
Page 123 of 212
14. Backing up the Database

14.1 Purpose of RMAN Backups
The primary purpose of RMAN backups is to protect your data. If a media failure or disaster occurs, then you can restore your backups and recover lost changes. You can also make backups to preserve data for long-time archival, and to transfer data.
14.2 Basic Concepts of RMAN Backups

In many cases, after your database has been configured in accordance with your backup strategy, you can back up the database by entering the following command at the RMAN prompt: RMAN> BACKUP DATABASE; RMAN uses the configured settings, the records of previous backups, and the control file record of the database structure to determine an efficient set of steps for the backup. RMAN then carries out these steps. You can run RMAN backups at any database in a Data Guard environment. Any backup of any database in the environment is usable for recovery of any other database as long as the backup is accessible. You can offload all backups of database files, including control file backups, to a physical standby database and thereby avoid consuming resources on the primary database.
14.3 Specifying Backup Output Options

If you specify only the minimum required options for an RMAN command such as BACKUP DATABASE, then RMAN determines the destination device, locations for backup output, and a backup tag automatically based on your configured environment and built-in RMAN defaults. You can also provide arguments to BACKUP to override these defaults.
14.3.1 Specifying the Device Type for an RMAN Backup

The BACKUP command takes a DEVICE TYPE clause that specifies whether to back up to disk or tape device. The following example illustrates a backup to disk. Example Specifying Device Type DISK BACKUP DATABASE DEVICE TYPE DISK; When you run BACKUP without a DEVICE TYPE clause, RMAN stores the backup on the configured default device (disk or SBT). You set the default device with the CONFIGURE DEFAULT DEVICE TYPE command
14.3.2 Specifying Backup Set or Copy for an RMAN Backup to Disk

RMAN can create backups on disk as image copies or as backup sets. You can override this default with the AS COPY or AS BACKUPSET clauses. To back up to disk as image copies, use BACKUP AS COPY. Example Making Image Copies BACKUP AS COPY DEVICE TYPE DISK DATABASE; To back up your data into backup sets, use the AS BACKUPSET clause. You can allow backup sets to be created on the configured default device, or direct them specifically to disk or tape, as shown in the following example. Example Making Backup Sets BACKUP AS BACKUPSET DATABASE; BACKUP AS BACKUPSET DEVICE TYPE DISK DATABASE; BACKUP AS BACKUPSET DEVICE TYPE SBT DATABASE;
Page 124 of 212
14.3.3 Specifying a Format for RMAN Backups

RMAN provides a range of options to name the files generated by the BACKUP command. RMAN uses the following set of rules to determine the format of the output files, which listed in order of precedence: 1. If a FORMAT parameter is specified on the BACKUP command, then this setting controls the generated filename. For example, you can direct the output to a specific location, as shown in the following command: BACKUP DATABASE FORMAT "/disk1/backup_%U"; # specifies a location on the file system In this case, backups are stored with generated unique filenames with the prefix /disk1/backup_. Note that the %U substitution variable, used to generate a unique string at this point in the filename, is required. You can also use the FORMAT parameter to name an ASM disk group as backup destination, as shown in the following example: BACKUP DATABASE FORMAT '+dgroup1'; # specifies an ASM disk group No %U is required in this case because Automatic Storage Management (ASM) generates unique file names as needed. However, you can specify %U if desired. Note: If you specify FORMAT when a flash recovery area is enabled, then RMAN obeys the FORMAT setting. If no location is specified in the FORMAT clause, then RMAN creates the backup in a platform-specific location. 2. If a FORMAT setting is configured for the specific channel used for the backup, then this setting controls the generated filename. 3. If a FORMAT setting is configured for the device type used for the backup, then this setting controls the generated filename. 4. If a flash recovery area is enabled during a disk backup, and if FORMAT is not specified, then RMAN creates the backup with an automatically generated name in the flash recovery area. 5. If none of the other conditions in this list apply, then the default location and filename format of the backup are platform-specific.
14.3.4 Specifying Multiple Formats for Disk Backups

Typically, you do not need to specify a format when backing up to tape because the default %U variable generates a unique filename for tape backups. When backing up to disk, however, you can specify a format to spread the backup across several drives for improved performance. In this case, allocate one DISK channel for each disk drive and specify the format string on the ALLOCATE CHANNEL command so that the filenames are on different disks. For example, issue the following command: RUN { ALLOCATE CHANNEL disk1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U'; ALLOCATE CHANNEL disk2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U'; ALLOCATE CHANNEL disk3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U'; BACKUP AS COPY DATABASE; } You can distribute backups in this manner by default in the future, by configuring channels as follows: CONFIGURE DEVICE TYPE DISK PARALLELISM 3; CONFIGURE DEFAULT DEVICE TYPE TO DISK; CONFIGURE CHANNEL 1 DEVICE TYPE DISK FORMAT '/disk1/%d_backups/%U'; CONFIGURE CHANNEL 2 DEVICE TYPE DISK FORMAT '/disk2/%d_backups/%U'; CONFIGURE CHANNEL 3 DEVICE TYPE DISK FORMAT '/disk3/%d_backups/%U'; BACKUP AS COPY DATABASE;
Page 125 of 212
14.4 Specifying Tags for an RMAN Backup

RMAN attaches a character string called a tag to every backup it creates, as a way of identifying the backup. You can either accept the default tag or specify your own with the TAG parameter of the BACKUP command.
14.4.1. About Backup Tags

User-specified tags are a useful way to indicate the purpose or usage of different classes of backups or copies. You can tag backup sets, proxy copies, datafile copies, or control file copies. For example, you can tag datafile copies that you intend to use in a SWITCH command as for_switch_only and file copies that should be used only for a RESTORE command as for_restore_only. Tags do not need to be unique, so multiple backup sets or image copies can have the same tag, for example, weekly_backup. Assume that you specify that a datafile should be restored from backups that have a specific tag. If more than one backup of the requested file has the desired tag, then RMAN restores the most recent backup that has the desired tag, within any constraints of the RESTORE command. In practice, tags are often used to distinguish a series of backups created as part of a single strategy, such as an incremental backup strategy. For example, you might create weekly incremental backups with a tag such as BACKUP TAG weekly_incremental. Many forms of the BACKUP command let you associate a tag with a backup, and many RESTORE and RECOVER commands let you specify a tag to restrict which backups to use in the RESTORE or RECOVER operation. If you do not explicitly specify a tag with the TAG parameter of the BACKUP command, then RMAN implicitly creates a default tag for backups (except for control file autobackups). The format of the tag is TAGYYYYMMDDTHHMMSS, where YYYY is the year, MM is the month, DD is the day, HH is the hour (in 24-hour format), MM is the minutes, and SS is the seconds. For example, a backup of datafile 1 may get the tag TAG20070208T133437. The date and time refer to when RMAN started the backup, in the time zone of the instance performing the backup. If multiple backup sets are created by one BACKUP command, then each backup piece has the same default tag. Tags are stored in uppercase, regardless of the case used when entering them. The maximum length of a backup tag is 30 bytes. Tags cannot use operating system environment variables or use special formats such as %T or %D.
14.4.2. Specifying Tags for Backup Sets and Image Copies

The characters in a tag must be limited to the characters that are legal in filenames on the target database file system. For example, Automatic Storage Management (ASM) does not support the use of the dash (-) in the filenames it uses internally, so a tag including a dash (such as weekly-incr) is not a legal tag name for backups in ASM disk groups. When you tag a backup set, the tag is an attribute of each backup piece in a given copy of a backup set. If you create a multiplexed backup set, then each copy of the backup set gets the same tag. Example creates one backup set with tag MONDAYBKP. Example -Applying a Tag to a Backup Set BACKUP AS BACKUPSET COPIES 1 DATAFILE 7 TAG mondaybkp; When you specify a tag for image copies, the tag applies to each individual copy. Example shows that copies of datafiles in tablespaces users and tools get the tag MONDAYCPY. Example Applying Tags to Image Copies BACKUP AS COPY TABLESPACE users, tools TAG mondaycpy; You can use FROM TAG to copy an image copy with a specific tag, and then use TAG to assign the output copy a different tag. Example creates new copies of all image copies of the database that have the tag full_cold_copy and gives the new copies the tag new_full_cold_copy. Example Assigning Tags to Output Copies BACKUP AS COPY COPY OF DATABASE FROM TAG full_cold_copy TAG new_full_cold_copy;
Page 126 of 212
14.5 Making Compressed Backups

For any use of the BACKUP command that creates backup sets, you can take advantage of RMAN support for binary compression of backup sets. Specify the AS COMPRESSED BACKUPSET option to the BACKUP command. The resulting backup sets are compressed with an algorithm optimized for efficient compression of Oracle Database files. No extra uncompression steps are required during recovery. Note: If you are backing up to tape and your tape device performs its own compression, and then you should not use both RMAN backup set compression and the media manager vendor's compression. In most instances you will get better results using the media manager's compression. Example backs up the entire database and archived logs to the configured default backup destination (disk or tape), producing compressed backup sets. Example Making Compressed Backups BACKUP AS COMPRESSED BACKUPSET DATABASE PLUS ARCHIVELOG; Binary compression creates some performance overhead during backup and restores operations. Binary compression consumes CPU resources, so compressed backups should not be scheduled when CPU usage is already high. However, the following circumstances may warrant paying the performance penalty: You are using disk-based backups when disk space in your flash recovery area or other disk-based backup destination is limited. You are performing your backups to some device over a network when reduced network bandwidth is more important than CPU usage. You are using some archival backup media such as CD or DVD, where reducing backup sizes saves on media costs and archival storage.
14.6 Backing up Database Files with RMAN

14.6.1 Making Whole Database Backups with RMAN
You can perform a whole database backup with the database mounted or open. To perform a whole database backup, from the RMAN prompt, use the BACKUP DATABASE command. You may want to exclude specified tablespaces from a whole database backup. You can persistently skip tablespaces across RMAN sessions by executing the CONFIGURE EXCLUDE command for each tablespace that you always want to skip. You can override the configured setting with BACKUP ... NOEXCLUDE. To back up the database: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Make sure the database is mounted or open. 3. Issue the BACKUP DATABASE command at the RMAN prompt. The simplest form of the command requires no options or parameters, as shown in the following example: BACKUP DATABASE; The following example backs up the database, switches the online redo logs, and includes archived logs in the backup: BACKUP DATABASE PLUS ARCHIVELOG; By archiving the logs immediately after the backup, you ensure that you have a full set of archived logs through the time of the backup. In this way, you guarantee that you can perform media recovery after restoring this backup.
14.6.2 Backing up Tablespaces and Datafiles with RMAN

You can back up one or more tablespaces with the BACKUP TABLESPACE command or one or more datafiles with the BACKUP DATAFILE command. When you specify tablespaces, RMAN translates the tablespace name internally into a list of datafiles. The database can be mounted or open. Tablespaces can be read/write or read-only. Note: Transportable tablespaces do not have to be in read/write mode for backup as in previous releases.
Page 127 of 212
RMAN automatically backs up the control file and the server parameter file (if the instance was started with a server parameter file) when datafile 1 is included in the backup. If control file autobackup is enabled, then RMAN writes the current control file and server parameter file to a separate autobackup piece. Otherwise, RMAN includes these files in the backup set that contains datafile 1. To back up tablespaces or datafiles: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. If the database instance is not started, then either mount or open the database. 3. Run the BACKUP TABLESPACE command or BACKUP DATAFILE command at the RMAN prompt. The following example backs up the users and tools tablespaces to tape: BACKUP DEVICE TYPE sbt TABLESPACE users, tools; The following example uses an SBT channel to back up datafiles 1 through 4 and a datafile copy stored at /tmp/system01.dbf to tape: BACKUP DEVICE TYPE sbt DATAFILE 1,2,3,4 DATAFILECOPY '/tmp/system01.dbf';
14.6.3 Backing up Control Files with RMAN

You can back up the control file when the database is mounted or open. RMAN uses a snapshot control file to ensure a read-consistent version. If the CONFIGURE CONTROLFILE AUTOBACKUP command is set to ON (by default it is OFF), then RMAN automatically backs up the control file and server parameter file after every backup and after database structural changes. The control file autobackup contains metadata about the previous backup, which is crucial for disaster recovery. Note: You can restore a backup of a control file made on one Data Guard database to any other database in the environment. Primary and standby control file backups are interchangeable. If the autobackup feature is not set, then you must manually back up the control file in one of the following ways: Run BACKUP CURRENT CONTROLFILE Include a backup of the control file within any backup by using the INCLUDE CURRENT CONTROLFILE option of the BACKUP command Back up datafile 1, because RMAN automatically includes the control file and server parameter file in backups of datafile 1 Note: If the control file block size is not the same as the block size for datafile 1, then the control file cannot be written into the same backup set as the datafile. RMAN writes the control file into a backup set by itself if the block size is different. The V$CONTROLFILE.BLOCK_SIZE column indicates the control file block size, whereas the DB_BLOCK_SIZE initialization parameter indicates the block size of datafile 1.
14.6.4 Making a Manual Backup of the Control File

A manual backup of the control file is not the same as a control file autobackup. RMAN makes a control file autobackup after the files specified in the BACKUP command are backed up. Thus, the autobackupunlike a manual control file backupcontains metadata about the backup that just completed. Also, RMAN can automatically restore autobackups without the use of a recovery catalog. To make a manual backup, you can either specify INCLUDE CURRENT CONTROLFILE when backing up other files or specify BACKUP CONTROLFILE. You can also back up control files copies on disk by specifying the CONTROLFILECOPY parameter. To manually back up the control file: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Make sure the target database is mounted or open. 3. Execute the BACKUP command with the desired control file clause. The following example backs up tablespace users to tape and includes the current control file in the backup: BACKUP DEVICE TYPE sbt TABLESPACE users INCLUDE CURRENT CONTROLFILE; The following example backs up the current control file to the default disk device:
Backingup the Database BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl'; The following example backs up the control file copy created in the previous example to tape: BACKUP AS COPY CURRENT CONTROLFILE FORMAT '/tmp/control01.ctl'; BACKUP DEVICE TYPE sbt CONTROLFILECOPY '/tmp/control01.ctl';
Page 128 of 212
If the control file autobackup feature is enabled, then RMAN makes two control file backups in these examples: the explicit backup of the files specified in the BACKUP command and the control file and server parameter file autobackup.
14.6.5 Backing up Server Parameter Files with RMAN

RMAN automatically backs up the current server parameter file in certain cases. The BACKUP SPFILE command backs up the parameter file explicitly. The server parameter file that is backed up is the one currently in use by the instance. To back up the server parameter file: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Make sure the target database is mounted or open. The database must have been started with a server parameter file. If the instance is started with a client-side initialization parameter file, then RMAN issues an error if you execute BACKUP ... SPFILE. 3. Execute the BACKUP ... SPFILE command. The following example backs up the server parameter file to tape: BACKUP DEVICE TYPE sbt SPFILE;
14.6.7 Backing up a Database in NOARCHIVELOG Mode

The only legal backup of a NOARCHIVELOG database is a closed, consistent backup. This script puts the database into the correct mode for a consistent, whole database backup and then backs up the database. The script assumes that control file autobackup is enabled for the database. Example -Backing Up a Database in NOARCHIVELOG Mode SHUTDOWN IMMEDIATE; # Start up the database in case it suffered instance failure or was # closed with SHUTDOWN ABORT before starting this script. STARTUP FORCE DBA; SHUTDOWN IMMEDIATE; STARTUP MOUNT; # this example uses automatic channels to make the backup BACKUP INCREMENTAL LEVEL 0 MAXSETSIZE 10M DATABASE TAG 'BACKUP_1'; # Now that the backup is complete, open the database. ALTER DATABASE OPEN; You can skip tablespaces, such as read-only tablespaces, but any skipped tablespace that has not been offline or read-only since its last backup is lost if the database has to be restored from a backup.
14.6.8 Backing up Archived Redo Logs with RMAN

Archived redo logs are the key to successful media recovery. You should back them up regularly. About Backups of Archived Redo Logs Several features of RMAN backups are specific to archived redo logs. For example, you can use BACKUP ... DELETE to delete one or all copies of archived redo logs from disk after backing them up to backup sets. Archived Redo Log Failover Even if your redo logs are being archived to multiple destinations and you use RMAN to back up archived redo logs, RMAN selects only one copy of the archived redo log file to include in the backup set. Because logs with the same
Page 129 of 212
log sequence number are identical, RMAN does not need to include more than one log copy. The archived redo log failover feature enables RMAN to complete a backup even when some archiving destinations are missing logs or contain logs with corrupt blocks. If at least one log corresponding to a given log sequence and thread is available in the flash recovery area or any of the archiving destinations, then RMAN tries to back it up. If RMAN finds a corrupt block in a log file during backup, it searches other destinations for a copy of that log without corrupt blocks. For example, assume that you archive logs 121 through 124 to two destinations: /arch1 and /arch2. Table shows the archived redo log record s in the control file. Table - Sample Archived Redo Log Records Sequence ---------121 122 123 124 Filename in /arch1 Filename in /arch2 --------------------------------------------------/arch1/archive1_121.arc /arch2/archive1_121.arc /arch1/archive1_122.arc /arch2/archive1_122.arc /arch1/archive1_123.arc /arch2/archive1_123.arc /arch1/archive1_124.arc /arch2/archive1_124.arc
However, unknown to RMAN, a user deletes logs 122 and 124 from the /arch1 directory. Afterward, you run the following backup: BACKUP ARCHIVELOG FROM SEQUENCE 121 UNTIL SEQUENCE 125; With failover, RMAN completes the backup, using logs 122 and 124 in /arch2. Online Redo Log Switching Another important RMAN feature is automatic online redo log switching. To make an open database backup of archived redo logs that includes the most recent online redo log, you can execute the BACKUP command with any of the following clauses: PLUS ARCHIVELOG ARCHIVELOG ALL ARCHIVELOG FROM...
Before beginning the backup, RMAN switches out of the current redo log group, and archives all online redo logs that have not yet been archived, up to and including the redo log group that was current when the command was issued. This feature ensures that the backup contains all redo generated before the start of the command. One of the most effective ways of backing up archived redo logs is the BACKUP ... PLUS ARCHIVELOG clause, which causes RMAN to do the following: 1. Runs the ALTER SYSTEM ARCHIVE LOG CURRENT statement. 2. Runs BACKUP ARCHIVELOG ALL. If backup optimization is enabled, then RMAN skips logs that it has already backed up to the specified device. 3. Backs up the rest of the files specified in BACKUP command. 4. Runs the ALTER SYSTEM ARCHIVE LOG CURRENT statement. 5. Backs up any remaining archived logs generated during the backup. If backup optimization is not enabled, then RMAN backs up the logs generated in step 1 plus all the logs generated during the backup. The preceding steps guarantee that datafile backups taken during the command are recoverable to a consistent state. Also, unless the online redo log is archived at the end of the backup, DUPLICATE is not possible with the backup. Backing Up Archived Redo Log Files To back up archived logs, use the BACKUP ARCHIVELOG command. Note that if backup optimization is enabled, then RMAN skips backups of archived logs that have already been backed up to the specified device. To back up archived redo log files: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Make sure the target database is mounted or open. 3. Execute the BACKUP ARCHIVELOG or BACKUP ... PLUS ARCHIVELOG command. The following example backs up the database and all archived redo logs:
Backingup the Database BACKUP DATABASE PLUS ARCHIVELOG;
Page 130 of 212
The following example uses a configured disk or SBT channel to back up one copy of each log sequence number for all archived redo logs: BACKUP ARCHIVELOG ALL; You can also specify a range of archived redo logs by time, SCN, or log sequence number, as in the following example: BACKUP ARCHIVELOG FROM TIME SYSDATE-30' UNTIL TIME 'SYSDATE-7';
14.6.9 Backing Up Only Archived Redo Logs That Need Backups

You can indicate that RMAN should automatically skip backups of archived redo logs in the following ways: Configuring backup optimization if you enable backup optimization, then the BACKUP ARCHIVELOG command skips backing up files when an identical archived log has already been backed up to the specified device type. An archived log is considered identical to another when it has the same DBID, thread, sequence number, and RESETLOGS SCN and time. Configure an archived redo log deletion policy if the deletion policy is configured with the BACKED UP integer TIMES clause, then a BACKUP ARCHIVELOG command copies the logs unless integer backups already exist on the specified device type. If integer backups of the logs exist, then the BACKUP ARCHIVELOG command skips the logs. The BACKUP ... NOT BACKED UP integer TIMES command specifies that RMAN should back up only those archived log files that have not been backed up at least integer times to the specified device. To determine the number of backups for a file, RMAN only considers backups created on the same device type as the current backup. The BACKED UP clause is a convenient way to back up archived logs to a specified device type. For example, you can specify that RMAN should keep two copies of each archived redo log on tape and skip additional backups. To back up archived redo logs that needs backups: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Make sure the target database is mounted or open. 3. Make sure that appropriate channels are configured for the backup. 4. Execute the BACKUP ARCHIVELOG command with the NOT BACKED UP clause. BACKUP ARCHIVELOG ALL NOT BACKED UP 2 TIMES; Deleting Archived Redo Logs after Backups The BACKUP ARCHIVELOG ... DELETE INPUT command deletes archived log files after they are backed up. This command eliminates the separate step of manually deleting archived redo logs. With DELETE INPUT, RMAN deletes only the specific copy of the archived log chosen for the backup set. With DELETE ALL INPUT, RMAN deletes each backed-up archived redo log file from all log archiving destinations. The BACKUP ... DELETE INPUT and DELETE ARCHIVELOG commands obey the archived redo log deletion policy for logs in all archiving locations. For example, if you specify that logs should only be deleted when backed up at least twice to tape, then BACKUP ... DELETE honors this policy. For the following procedure, assume that you archive to /arc_dest1, /arc_dest2, and the flash recovery area. To delete archived redo logs after a backup: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Make sure that the target database is mounted or open. 3. Run the BACKUP command with the DELETE INPUT clause. Assume that you run the following BACKUP command: BACKUP DEVICE TYPE sbt ARCHIVELOG ALL DELETE ALL INPUT; In this case, RMAN backs up only one copy of each log sequence number in these archiving locations. RMAN does not delete any logs from the flash recovery area, but it deletes all copies of any log that it backed up from the other archiving destinations. The logs in the flash recovery area that is eligible for deletion will be automatically removed by the database when space is needed.
Page 131 of 212
If you had specified DELETE INPUT rather than DELETE ALL INPUT, then RMAN would only delete the specific archived redo log files that it backed up. For example, RMAN would delete the logs in /arc_dest1 if these files were used as the source of the backup, but leave the contents of the /arc_dest2 intact.
14.7 Making and Updating Incremental Backups

As an incremental backup copies only datafile blocks that have changed since a specified previous backup. An incremental backups is either a cumulative incremental backup or differential incremental backup. Although the content of the backups are the same, BACKUP DATABASE and BACKUP INCREMENTAL LEVEL 0 DATABASE are different. A full backup is not usable as part of an incremental strategy, whereas a level 0 incremental backup is the basis of an incremental strategy. No RMAN command can change a full backup into a level 0.As with full backups; RMAN can make open incremental backups of an ARCHIVELOG mode database. If the database is in NOARCHIVELOG mode, then RMAN can only make incremental backups after a consistent shutdown.
14.7.1 Purpose of Incremental Backups

The primary reasons for making incremental backups part of your strategy is: Faster daily backups if block change tracking is enabled Ability to roll forward datafile image copies, thereby reducing recovery time and avoiding repeated full backups. Less bandwidth consumption when backing up over a network. Improved performance when the aggregate tape bandwidth for tape write I/Os is much less than the aggregate disk bandwidth for disk read I/Os. Possibility of recovering changes to objects created with the NOLOGGING option. For example, direct load inserts do not create redo log entries, so their changes cannot be reproduced with media recovery. Direct load inserts do change data blocks, however, and so these blocks are captured by incremental backups. Synchronize a physical standby database with the primary database. You can use the RMAN BACKUP INCREMENTAL FROM SCN command to create a backup on the primary database that starts at the current SCN of the standby, which you can then use to roll forward the standby database.
14.7.2 Planning an Incremental Backup Strategy

Choose a backup strategy according to an acceptable MTTR (mean time to recover). For example, you can implement a three-level backup scheme so that a full or level 0 backup is taken monthly, a cumulative level 1 is taken weekly, and a differential level 1 is taken daily. In this strategy, you never have to apply more than a day of redo for complete recovery. When deciding how often to take full or level 0 backups, a good rule of thumb is to take a new level 0 backup whenever 20% or more of the data has changed. If the rate of change to your database is predictable, then you can observe the size of your incremental backups to determine when a new level 0 is appropriate. The following SQL query determines the number of blocks written to an incremental level 1 backup of each datafile with at least 20% of its blocks backed up: SELECT FILE#, INCREMENTAL_LEVEL, COMPLETION_TIME, BLOCKS, DATAFILE_BLOCKS FROM WHERE AND V$BACKUP_DATAFILE INCREMENTAL_LEVEL > 0 BLOCKS / DATAFILE_BLOCKS > .2
ORDER BY COMPLETION_TIME;
Page 132 of 212
Compare the number of blocks in level 1 backups to a level 0 backup. For example, if you only create level 1 cumulative backups, then take a new level 0 backup when the most recent level 1 backup is about half of the size of the level 0 backup. An effective way to conserve disk space is to make incremental backups to disk, and then offload the backups to tape with BACKUP AS BACKUPSET. Incremental backups are generally smaller than full backups, which limits the space required to store them until they are moved to tape. When the incremental backups on disk are backed up to tape, the tape is more likely to stream because all blocks of the incremental backup are copied to tape. There is no possibility of delay due to time required for RMAN to locate changed blocks in the datafiles. Another strategy is to use incrementally updated backups. In this strategy, you create an image copy of each datafile, and then periodically roll forward this copy by making and then applying a level 1 incremental backup. In this way you avoid the overhead of making repeated full image copies of your datafiles, but enjoy all of the advantages. In a Data Guard environment, you can offload incremental backups to a physical standby database. Incremental backups of a standby and primary database are interchangeable. Thus, you can apply an incremental backup of a standby database to a primary database, or apply an incremental backup of a primary database to a standby database. You can also enable block change tracking at a standby database, regardless of whether it is enabled at any other database in the Data Guard environment. In this way, RMAN automatically optimizes incremental backups of the standby database.
14.7.3 Making Incremental Backups

After starting RMAN, run the BACKUP INCREMENTAL command at the RMAN prompt. By default incremental backups are differential. To make an incremental backup: 1. Start RMAN and connect to a target database and a recovery catalog (if used). 2. Make sure the target database is mounted or open. 3. Execute the BACKUP INCREMENTAL command with the desired options. Use the LEVEL parameter to indicate the incremental level. The following example makes a level 0 incremental database backup. BACKUP INCREMENTAL LEVEL 0 DATABASE; The following example makes a differential incremental backup at level 1 of the SYSTEM and tools tablespaces. It will only back up those data blocks changed since the most recent level 1 or level 0 backup. BACKUP INCREMENTAL LEVEL 1 TABLESPACE SYSTEM, tools; The following example makes a cumulative incremental backup at level 1 of the tablespace users, backing up all blocks changed since the most recent level 0 backup. BACKUP INCREMENTAL LEVEL 1 CUMULATIVE TABLESPACE users;
14.7.4 Incrementally Updating Backups

By incrementally updating backups, you can avoid the overhead of making full image copy backups of datafiles, while also minimizing time required for media recovery of your database. For example, if you run a daily backup script, then you never have more than one day of redo to apply for media recovery. To incrementally update datafile backups: 1. Make a full image copy backup of a datafile. 2. At regular intervals (such as daily), make level 1 incremental backups of the datafile and apply them to the image copy backup. This technique rolls forward the backup to the time when the level 1 incremental was made. RMAN can restore this incrementally updated backup and apply changes from the redo log. The result is the same as restoring a datafile backup taken at the SCN of the most recently applied incremental level 1 backup. Note: If you run the RECOVER COPY command daily, then a continuously updated image copy cannot satisfy a recovery window of more than one day. The incrementally updated backup feature is an optimization for fast media recovery. Incrementally Updating Backups: Basic Example
Page 133 of 212
To create incremental backups for use in an incrementally updated backups strategy, use the BACKUP ... FOR RECOVER OF COPY WITH TAG form of the BACKUP command. The command is best understood in the context of a sample script that implements the strategy. This script in Example, run on a regular basis, is all that is required to implement a strategy based on incrementally updated backups. Example - Basic Incremental Update Script RUN { RECOVER COPY OF DATABASE WITH TAG 'incr_update'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; } To understand the script and the strategy, it is necessary to understand the effects of these two commands when no datafile copies or incremental backup s exist. Note two important features: The BACKUP command in Example does not always create a level 1 incremental backup. The RECOVER command in Example causes RMAN to apply any available incremental level 1 backups to a set of datafile copies with the specified tag. The effect of the script is shown in the following table. The columns show the effects of the first run of the script, the second run of the script, and then the third and all subsequent run of the script. Each time a datafile is added to the database, an image copy of the new datafile is created the next time the script runs. The next run makes the first level 1 incremental for the added datafile. On all subsequent runs the new datafile is processed like any other datafile. You must use tags to identify the incremental level 0 datafile copies created for use in this strategy so that they do not interfere with other backup strategies you implement. If you use multiple incremental backup strategies, then RMAN cannot unambiguously create incremental level 1 backups unless you tag level 0 backups. The incremental level 1 backups to apply to those image copies are selected based upon the checkpoint SCNs of the image copy datafiles and the available incremental level 1 backups. The tag used on the image copy being recovered is not a factor in the selection of the incremental level backups. In practice, you would schedule the script in Example to run after each day, possibly at midnight. After the third run of the script, the following files would be available for a point-in-time recovery: An image copy of the database, as of the checkpoint SCN of the receding run of the script, 24 hours earlier An incremental backup for the changes after the checkpoint SCN of receding run Archived redo logs including all changes between the checkpoint SCN of the image copy and the current time if at some point during the following 24 hours you need to restore and recover your database, then you can restore the datafiles from the incrementally updated datafile copies. You can then apply changes from the most recent incremental level 1 and the redo logs to reach the d esired SCN. At most, you have 24 hours of redo to apply, which limits how long point-in-time recovery will take. Incrementally Updated Backups: Advanced Example You can extend the basic script in Example to provide fast recoverability to a window greater than 24 hours. Example shows how to maintain a window of seven days by specifying the beginning time of your window of recoverability in the RECOVER command. Example - Advanced Incremental Update Script RUN {
Backingup the Database RECOVER COPY OF DATABASE WITH TAG 'incr_update' UNTIL TIME 'SYSDATE - 7'; BACKUP INCREMENTAL LEVEL 1 FOR RECOVER OF COPY WITH TAG 'incr_update' DATABASE; }
Page 134 of 212
The effect of the script is shown in the following table. The columns show the effects of the first run of the script, the second through seventh run of the scripts, and then each subsequent run of the script.
14.8. Using Block Change Tracking to Improve Incremental Backup Performance

The block change tracking feature for incremental backups improves backup performance by recording changed blocks for each datafile.
14.8.1. About Block Change Tracking

If block change tracking is enabled on a primary or standby database, then RMAN uses a block change tracking file to identify changed blocks for incremental backups. By reading this small bitmap file to determine which blocks changed, RMAN avoids having to scan every block in the datafile that it is backing up. Block change tracking is disabled by default. Nevertheless, the benefits of avoiding full datafile scans during backup are considerable, especially if only a small percentage of data blocks are changed between backups. If your backup strategy involves incremental backups, then block change tracking is recommended. Block change tracking in no way changes the commands used to perform incremental backups. The change tracking files themselves generally require little maintenance after initial configuration. Space Management in the Block Change Tracking File The change tracking file maintains bitmaps that mark changes in the datafiles between backups. The database performs a bitmap switch before each backup. Oracle Database automatically manages space in the change tracking file to retain block change data that covers the 8 most recent backups. After the maximum of 8 bitmaps is reached, the most recent bitmap is overwritten by the bitmap that tracks the current changes. The first level 0 incremental backup scans the entire datafile. Subsequent incremental backups use the block change tracking file to scan only the blocks that have been marked as changed since the last backup. An incremental backup can be optimized only when it is based on a parent backup that was made after the start of the oldest bitmap in the block change tracking file. Consider the 8-bitmap limit when developing your incremental backup strategy. For example, if you make a level 0 database backup followed by 7 differential incremental backups, then the block change tracking file now includes 8 bitmaps. If you then make a cumulative level 1 incremental backup, then RMAN cannot optimize the backup because the bitmap corresponding to the parent level 0 backup is overwritten with the bitmap that tracks the current changes. Location of the Block Change Tracking File One block change tracking file is created for the whole database. By default, the change tracking file is created as an Oracle-managed file in the destination specified by the DB_CREATE_FILE_DEST initialization parameter. You can also specify the name of the block change tracking file by placing it in any location you choose. RMAN does not support backup and recovery of the change tracking file. The database resets the change tracking file when it determines that the change tracking file is invalid. If you restore and recover the whole database or a subset, then the database clears the block change tracking file and starts tracking changes again. After you make a level 0 incremental backup, the next incremental backup is able to use change tracking data. Size of the Block Change Tracking File The size of the block change tracking file is proportional to the size of the database and the number of enabled threads of redo. The size of the block change tracking file can increase and decrease as the database changes. The size is not related to the frequency of updates to the database. Typically,
Page 135 of 212
the space required for block change tracking is approximately 1/30,000 the size of the data blocks to be tracked. The following factors that may cause the file to be larger than this estimate suggests: To avoid the overhead of allocating space as your database grows, the block change tracking file size starts at 10 MB. New space is allocated in 10 MB increments. Thus, for any database up to approximately 300 GB, the file size is no smaller than 10 MB, for up to ap proximately 600 GB the file size is no smaller than 20 MB, and so on. For each datafile, a minimum of 320 KB of space is allocated in the block change tracking file, regardless of the size of the datafile. Thus, if you have a large number of relatively small datafiles, the change tracking file is larger than for databases with a smaller number of larger datafiles containing the same data.
14.8.2 Enabling and Disabling Block Change Tracking

You can enable block change tracking when the database is either open or mounted. This section assumes that you intend to create the block change tracking file as an Oracle-managed file in the database area, which is where the database maintains active database files such as datafiles, control files, and online redo log files. To enable block change tracking: 1. Start SQL*Plus and connect to a target database with administrator privileges. 2. Make sure that the DB_CREATE_FILE_DEST initialization parameter is set. If the parameter is not set, and if the database is open, then you can set the parameter with the following form of the ALTER SYSTEM statement: ALTER SYSTEM SET DB_CREATE_FILE_DEST = '/disk1/bct/' SCOPE=BOTH SID='*'; 3. Enable block change tracking. Execute the following ALTER DATABASE statement: ALTER DATABASE ENABLE BLOCK CHANGE TRACKING; You can also create the change tracking file in a location you choose yourself by using the following form of SQL statement: ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE '/mydir/rman_change_track.f' REUSE; The REUSE option tells Oracle Database to overwrite any existing file with the specified name.
14.8.3 Disabling Block Change Tracking

This section assumes that the block change tracking feature is current enabled. To disable block change tracking: 1. Start SQL*Plus and connect to a target database with administrator privileges. 2. Ensure that the target database is mounted or open. 3. Disable block change tracking. Execute the following ALTER DATABASE statement: ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; If the block change tracking file was stored in the database area, then it is deleted when you disable block change tracking.
14.8.4 Checking Whether Change Tracking is Enabled

You can query the V$BLOCK_CHANGE_TRACKING view to determine whether change tracking is enabled, and if it is, the filename of the block change tracking file. To determine whether change tracking is enabled: Enter the following query in SQL*Plus (sample output included): COL STATUS FORMAT A8
Backingup the Database COL FILENAME FORMAT A60
Page 136 of 212
SELECT STATUS, FILENAME FROM V$BLOCK_CHANGE_TRACKING;
STATUS
FILENAME
-------- -----------------------------------------------------------ENABLED /disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg
14.8.5 Changing the Location of the Block Change Tracking File

To move the change tracking file, use the ALTER DATABASE RENAME FILE statement. The database must be mounted. The statement updates the control file to refer to the new location and preserves the contents of the change tracking file. If you cannot shut down the database, then you can disable and enable block change tracking. In this case, you lose the contents of the existing block change tracking file. To change the location of the change tracking file: 1. Start SQL*Plus and connect to a target database. 2. If necessary, determine the current name of the change tracking file: SQL> SELECT FILENAME FROM V$BLOCK_CHANGE_TRACKING; 3. If possible, shut down the database. For example: SQL> SHUTDOWN IMMEDIATE If you shut down the database, then skip to the next step. If you choose not to shut down the database, then execute the following SQL statements and skip all remaining steps: SQL> ALTER DATABASE DISABLE BLOCK CHANGE TRACKING; SQL> ALTER DATABASE ENABLE BLOCK CHANGE TRACKING USING FILE 'new_location'; In this case you lose the contents of the block change tracking file. Until the next time you complete a level 0 incremental backup, RMAN must scan the entire file. 4. Using host operating system commands, move the change tracking file to its new location. 5. Mount the database and move the change tracking file to a location that has more space. For example: ALTER DATABASE RENAME FILE '/disk1/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg' TO '/disk2/bct/RDBMS/changetracking/o1_mf_2f71np5j_.chg'; This statement changes the location of the change tracking file while preserving its contents. 6. Open the database: SQL> ALTER DATABASE OPEN;
14.9 Backing up RMAN Backups

This section explains how to back up backup sets and image copies.
14.9.1. About Backups of Backups

You can use the BACKUP BACKUPSET command to back up backup sets produced by other backup jobs. You can also use BACKUP RECOVERY AREA to back up recovery files created in the current and all previous flash recovery area destinations. Recovery files are full and incremental backup sets, control file autobackups, datafile copies, and archived redo logs. Only SBT backups are supported for BACKUP RECOVERY AREA. The preceding commands are especially useful in the following scenarios: Ensuring that all backups exist both on disk and on tape.
Page 137 of 212
Moving backups from disk to tape and then freeing space on disk. This task is especially important when the database uses a flash recovery area so that the space can be reused as needed.
Note: You cannot duplex backups when running BACKUP BACKUPSET. RMAN always makes one and only one copy on the specified media when performing BACKUP BACKUPSET. You can also the BACKUP COPY OF command to back up image copies of datafiles, control files, and archived redo logs. The output of this command can be either backup sets or image copies, so you can generate backup sets from image copies. This form of backup is used to back up a database backup created as image copies on disk to tape.
14.9.2 Multiple Copies of Backup Sets

BACKUP BACKUPSET creates additional copies of backup pieces in a backup set, but does not create a new backup set. Thus, BACKUP BACKUPSET is similar to using the DUPLEX or MAXCOPIES option of BACKUP. The extra copy of a backup set created by BACKUP BACKUPSET is not a new backup set, just as copies of a backup set produced by other forms of the BACKUP command are not separate backup sets.
14.9.3 Effect of a Backup Retention Policy on Backups of Backups

For the purposes of a backup retention policy based on redundancy, a backup set is counted as one instance of a backup. This statement is true even if there are multiple copies of the backup pieces that make up backup set, such as when a backup set has been backed up from disk to tape. For the purposes of a recovery window retention policy, either all of the copies of a backup set are obsolete, or none of them are. This point is easiest to grasp when viewing the output of the LIST and REPORT commands. To view the effect of a backup retention policy on backups of backups: 1. Back up a datafile. The following example backs up datafile 5: BACKUP AS BACKUPSET DATAFILE 5; 2. Run the LIST command for the datafile backup in the preceding step. For example, run the following command (sample output included). LIST BACKUP OF DATAFILE 5 SUMMARY; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- --18 B F A DISK 04-AUG-07 1 1 NO
TAG20070804T160 134 3. Use the backup set key from the previous step to back up the backup set. For example, enter the following command: BACKUP BACKUPSET 18; 4. Run the same LIST command that you ran in step 2. For example, run the following command (sample output included). LIST BACKUP OF DATAFILE 5 SUMMARY; List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- --18 B F A DISK 04-AUG-07 1 2 NO
TAG20070804T160 134 Only one backup set is shown in this output, but there are now two copies of it. 5. Generate a report to see the effect of these copies under a redundancy-based backup retention policy.
Backingup the Database For example, issue the following command: REPORT OBSOLETE REDUNDANCY 1;
Page 138 of 212
None of the copies is reported as obsolete because both copies of the backup set have the same values for set_stamp and set_count. 6. Generate a report to see the effect of these copies under a recovery window-based backup retention policy. For example, issue the following command: REPORT OBSOLETE RECOVERY WINDOW 1 DAY; None of the copies of the backup set is reported as obsolete or based on the CHECKPOINT_CHANGE# of this backup set, with respect to the current time and the availability of other backups.
14.9.4 Backing Up Backup Sets with RMAN

This section explains how to use the BACKUP BACKUPSET command to copy backup sets from disk to tape. The procedure assumes that you have already configured an SBT device as your default device. To back up backup sets from disk to tape: 1. If you are backing up a subset of available backup sets, then execute the LIST BACKUPSET command to obtain their primary keys. The following example lists the backup sets in summary form: RMAN> LIST BACKUPSET SUMMARY;
List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Comp Tag --- -- -- - ----------- --------------- ------- ------- ---- --1 2 3 B B B F F F A DISK A DISK A DISK 28-MAY-07 29-MAY-07 30-MAY-07 1 1 1 1 1 1 NO NO NO TAG20070528T132432 TAG20070529T132433 TAG20070530T132434
The following example lists details about backup set 3 in verbose form: RMAN> LIST BACKUPSET 3; List of Backup Sets =================== BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ --------------3 Full 8.33M DISK 00:00:01 30-MAY-07 Tag: TAG20070530T132434
BP Key: 3
Status: AVAILABLE
Compressed: NO
Piece Name: /disk1/oracle/dbs/c-35764265-20070530-02 Control File Included: Ckp SCN: 397221 Ckp time: 30-MAY-07
SPFILE Included: Modification time: 30-MAY-07 SPFILE db_unique_name: PROD DELETE INPUT; The following example backs up only the backup sets with the primary key 1 and 2 to tape and then deletes the input disk backups: BACKUP BACKUPSET 1,2 DELETE INPUT; 3. Optionally, execute the LIST command to see a listing of backup sets and pieces. The output lists all copies, including backup piece copies created by BACKUP BACKUPSET.
Page 139 of 212
14.9.5 Backing up Image Copy Backups with RMAN

This section explains how to use the BACKUP command to back up image copies to tape. It is assumed that you have configured an SBT device as your default device. Note that when backing up image copies that have multiple copies of the datafiles, specifying tags for the backups makes it easier to identify the input image copy. All image copies of datafiles have tags. The tag of an image copy is inherited by default when the image copy is backed up as a new image copy. To back up image copies from disk to tape: 1. Issue the BACKUP ... COPY OF or BACKUP DATAFILECOPY command. The following example backs up datafile copies that have the tag DBCopy: BACKUP DATAFILE COPY FROM TAG monDBCopy; The following example backs up the latest image copies of a database to tape, assigns the tag QUARTERLY_BACKUP, and deletes the input disk backups: BACKUP DEVICE TYPE sbt TAG "quarterly_backup" COPY OF DATABASE DELETE INPUT; 2. Optionally, issue the LIST command to see a listing of backup sets. The output lists all copies, including backup piece copies created by BACKUP BACKUPSET.
Reporting on RMAN Operations
Page 140 of 212
15. Reporting on RMAN Operations

15.1 Purpose of RMAN Reporting
As part of your backup and recovery strategy, you should periodically run reports that indicate what you have backed up. You should also determine which datafiles need backups or which files have not been backed up recently. Also, you can preview which backups RMAN would need to restore if a problem were to occur. Another important aspect of backup and recovery is monitoring space usage. If you back up to disk, then it is possible for the disk to fill, which can create performance problems or even cause the database to halt. You can use RMAN to determine whether a backup is an obsolete backup and can therefore be deleted. You may also need to obtain historical information about RMAN jobs. For example, you may want to know how many backup jobs have been issued, the status of each backup job (for example, whether it failed or completed), when a job started and finished, and what type of backup was performed.
15.2 Basic Concepts of RMAN Reporting

RMAN always stores its RMAN repository of metadata in the control file of each target database on which it performs operations. For example, suppose that you use RMAN to back up the prod1 and prod2 databases. RMAN stores the metadata for backups of prod1 in the control file of prod1, and the metadata for backups of prod2 in the control file of prod2.Optionally, you can use RMAN with a recovery catalog. In this case, RMAN maintains an additional repository of metadata in a set of tables in a separate recovery catalog database. For example, you could create a recovery catalog in prod3. You can register multiple target databases in this recovery catalog. For example, if you register prod1 and prod2 in the recovery catalog stored in prod3, then RMAN stores metadata about its backups of prod1 and prod2 in the recovery catalog schema. You can access metadata from the RMAN repository in several different ways: The RMAN LIST and REPORT commands provide extensive information on available backups and how they can be used to restore and recover your database. When the database is open, a number of V$ views provide direct access to RMAN repository records in the control file of each target database. Some V$ views such as V$DATAFILE_HEADER, V$PROCESS, and V$SESSION contain information not found in the recovery catalog views. If your database is registered in a recovery catalog, then RC_ views provide direct access to the RMAN repository data stored in the recovery catalog. The RC_ views that mostly correspond to the V$ views. The RESTORE ... PREVIEW and RESTORE ... VALIDATE HEADER commands lists the backups that RMAN could restore to the specified time. RESTORE ... PREVIEW queries the metadata and does not actually read the backup files. The RESTORE ... VALIDATE HEADER command performs the same work, but in addition to listing the files needed for restore and recovery, the command validates the backup file headers to determine whether the files on disk or in the media management catalog correspond to the metadata in the RMAN repository. The RMAN repository can sometimes fail to reflect the reality on disk and tape. For example, a user may delete a backup with an operating system utility, so that the RMAN repository incorrectly reports the backup as available. You can use commands such as CHANGE, CROSSCHECK, and DELETE to update the RMAN repository to reflect the actual state of available backups. Otherwise, the output of the commands and views may be misleading, which means that RMAN may not be able to find the backups to restore and recover your database.
15.3 Listing Backups and Recovery-Related Objects

The LIST command uses the information in the RMAN repository to provide lists of backups and other objects relating to backup and recovery.
Page 141 of 212
15.3.1. About the LIST Command

The primary purpose of the LIST command is to list backup and copies. For example, you can list: Backups and proxy copies of a database, tablespace, datafile, archived redo log, or control file Backups that have expired Backups restricted by time, path name, device type, tag, or recoverability Archived redo log files and disk copies
The primary purpose of the LIST command is to list backup and copies. Besides backups and copies, the RMAN can list other types of data.
15.3.2 Listing Backups and Copies

Specify the desired objects with the listObjList or recordSpec clause. If you do not specify an object, then RMAN displays copies of all database files and archived redo log files. By default, RMAN serially lists each backup or proxy copy and then identifies the files included in the backup. You can also list backups by file. By default, RMAN lists in verbose mode, which means that it provides extensive, multiline information. You can also list backups in a summary mode if the verbose mode generates too much output. To list backups and copies: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. To view a summary report of all backups and copies, execute the LIST command with the SUMMARY option. The following command prints a summary of all RMAN backups: LIST BACKUP SUMMARY; Sample output follows: List of Backups =============== Key TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
------- -- -- - ----------- --------------- ------- ------- ---------- --1 B A A SBT_TAPE 21-OCT-07 1 1 NO
TAG20071021T094505 2 B F A SBT_TAPE 21-OCT-07 1 1 NO
TAG20071021T094513 3 B A A SBT_TAPE 21-OCT-07 1 1 NO
TAG20071021T094624 4 B F A SBT_TAPE 21-OCT-07 1 1 NO
TAG20071021T094639 5 B F A DISK 04-NOV-07 1 1 YES
TAG20071104T195949 3. To view verbose output for backups and copies, execute the LIST command without the SUMMARY option. The following commands list RMAN backups and copies with the default verbose output: LIST BACKUP; LIST COPY; Sample output for LIST BACKUP and LIST COPY follows: List of Backup Sets ===================
BS Key
Size
Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------www.wilshiresoft.com info@wilshiresoft.com Wilshire Software Technologies Ph: 2761-2214 / 5577-2214 Rev. Dt: 10-Oct-08 Version: 6
Reporting on RMAN Operations 7 136M BP Key: 7 Piece Name: DISK 00:00:20 04-NOV-06
Page 142 of 212
Status: AVAILABLE
Compressed: NO
Tag: TAG20071104T200759
/d2/RDBMS/backupset/2007_11_04/o1_mf_annnn_TAG20071104T200759_ztjxx3k8_.bkp
List of Archived Logs in backup set 7 Thrd Seq Low SCN Low Time Next SCN Next Time
---- ------- ---------- --------- ---------- --------1 1 1 1 2 3 173832 174750 174755 21-OCT-06 174750 21-OCT-06 174755 21-OCT-06 174758 21-OCT-06 21-OCT-06 21-OCT-06
BS Key
Type LV Size
------- ---- -- ---------- ----------- ------------ --------------8 Full 2M DISK Status: AVAILABLE 00:00:01 04-NOV-06 Tag: TAG20071104T200829
BP Key: 8
Compressed: NO
Piece Name: /disk1/oracle/dbs/c-774627068-20071104-01 Controlfile Included: Ckp SCN: 631510 Ckp time: 04-NOV-06
SPFILE Included: Modification time: 21-OCT-06
List of Datafile Copies =======================
Key
File S Completion Time Ckp SCN
Ckp Time
------- ---- - --------------- ---------- --------------1 7 A 11-OCT-06 360072 11-OCT-06
Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7bf82_.dbf Tag: DF7COPY
A 11-OCT-06
360244
11-OCT-06
Name: /work/orcva/RDBMS/datafile/o1_mf_tbs_2_2lv7qmcj_.dbf Tag: TAG20071011T184835
List of Control File Copies ===========================
Key
S Completion Time Ckp SCN
Ckp Time
------- - --------------- ---------- --------------3 A 11-OCT-06 360380 11-OCT-06
Name: /d2/RDBMS/controlfile/o1_mf_TAG20071011T185335_2lv80zqd_.ctl Tag: TAG20071011T185335
List of Archived Log Copies for database with db_unique_name RDBMS =====================================================================
Page 143 of 212
Key
Thrd Seq
S Low Time
------- ---- ------- - --------1 1 1 A 11-OCT-06
Name: /work/arc_dest/arcr_1_1_603561743.arc
A 11-OCT-06
A 11-OCT-06
4. To list backups by file, execute LIST with the BY FILE option, specifying the desired objects to list and options. For example, you can enter: LIST BACKUP BY FILE;
Sample output follows: List of Datafile Backups
Listing Backups and Recovery-Related Objects ========================
File Key
TY LV S Ckp SCN
Ckp Time
#Pieces #Copies Compressed Tag
---- ------- 1 5 B
-- - ---------- --------- ------- ------- ---------- --F A 631092 04-NOV-06 1 1 YES
TAG20071104T195949 2 B F A 175337 21-OCT-06 1 1 NO
TAG20071021T094513 2 5 B F A 631092 04-NOV-06 1 1 YES
TAG20071104T195949 2 B F A 175337 21-OCT-06 1 1 NO
TAG20071021T094513
... some rows omitted
List of Archived Log Backups ============================
Thrd Seq
Low SCN
Low Time
BS Key
S #Pieces #Copies Compressed Tag
---- ------- ---------- --------- ------- - ------- ------- ---------- --1 1 173832 21-OCT-06 7 A 1 1 NO
TAG20071104T200759 1 TAG20071021T094505
A 1
NO
Reporting on RMAN Operations 1 2 174750 21-OCT-06 7 A 1 1 NO
Page 144 of 212
TAG20071104T200759 1 TAG20071021T094505 ... some rows omitted 1 38 575472 03-NOV-06 7 A 1 1 NO A 1 1 NO
TAG20071104T200759 1 39 617944 04-NOV-06 7 A 1 1 NO
TAG20071104T200759
List of Controlfile Backups =========================== CF Ckp SCN Ckp Time BS Key S #Pieces #Copies Compressed Tag
---------- --------- ------- - ------- ------- ---------- --631510 631205 04-NOV-06 8 04-NOV-06 6 A 1 A 1 1 1 NO NO TAG20071104T200829 TAG20071104T200432
List of SPFILE Backups ====================== Modification Time BS Key S #Pieces #Copies Compressed Tag
----------------- ------- - ------- ------- ---------- --21-OCT-06 21-OCT-06 8 6 A 1 A 1 1 1 NO NO TAG20071104T200829 TAG20071104T200432
15.3.3 Listing Selected Backups and Copies

You can specify several different conditions to narrow your LIST output. To list selected backups and copies: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Run LIST COPY or LIST BACKUP with the listObjList or recordSpec clause. For example, enter any of the following commands: # lists backups of all files in database LIST BACKUP OF DATABASE; # lists copy of specified datafile LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf'; # lists specified backup set LIST BACKUPSET 213; # lists datafile copy LIST DATAFILECOPY '/tmp/tools01.dbf'; You can also restrict the search by specifying the maintQualifier or RECOVERABLE clause. For example, enter any of the following commands: # specify a backup set by tag LIST BACKUPSET TAG 'weekly_full_db_backup'; # specify a backup or copy by device type LIST COPY OF DATAFILE 'ora_home/oradata/trgt/system01.dbf' DEVICE TYPE sbt; # specify a backup by directory or path LIST BACKUP LIKE '/tmp/%'; # specify a backup or copy by a range of completion dates
Page 145 of 212
LIST COPY OF DATAFILE 2 COMPLETED BETWEEN '10-DEC-2002' AND '17-DEC-2002'; # specify logs backed up at least twice to tape LIST ARCHIVELOG ALL BACKED UP 2 TIMES TO DEVICE TYPE sbt; 3. Examine the output. The output depends upon the options you pass to the LIST command. For example, the following lists copies of datafile 1: RMAN> LIST BACKUP OF DATAFILE 1;
List of Backup Sets ===================
BS Key Type LV Size
------- ---- -- ---------- ----------- ------------ --------------2 Full 230M SBT_TAPE 00:00:49 21-OCT-06 Tag: TAG20071021T094513
BP Key: 2
Status: AVAILABLE
Compressed: NO
Handle: 02f4eatc_1_1
Media: /smrdir
List of Datafiles in backup set 2 File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ---1 Full 175337 21-OCT-06 /oracle/dbs/tbs_01.f
BS Key
Type LV Size
------- ---- -- ---------- ----------- ------------ --------------5 Full 233M DISK 00:04:30 04-NOV-06 Tag: TAG20071104T195949
BP Key: 5 Piece Name:
Status: AVAILABLE
Compressed: NO
/disk1/2007_11_04/o1_mf_nnndf_TAG20071104T195949_ztjxfvgz_.bkp List of Datafiles in backup set 5 File LV Type Ckp SCN Ckp Time Name
---- -- ---- ---------- --------- ---1 Full 631092 04-NOV-06 /oracle/dbs/tbs_01.f
15.3.4 Listing Database Incarnations

Each time an OPEN RESETLOGS operation is performed on a database, this operation creates a new incarnation of the database. When performing incremental backups, RMAN can use a backup from a previous incarnation or the current incarnation as a basis for subsequent incremental backups. When performing restore and recovery, RMAN can use backups from a previous incarnation in restore and recovery operations just as it would use backups from the current incarnation, as long as all archived logs are available. To list database incarnations: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Run the LIST INCARNATION command, as shown in the following example: LIST INCARNATION; If you are using a recovery catalog, and if you register multiple target databases in the same catalog, then you ca n distinguish them by using the OF DATABASE option: LIST INCARNATION OF DATABASE prod3; Refer to Oracle Database Backup and Recovery Reference for an explanation of the various column headings in the LIST output). Sample output follows:
Reporting on RMAN Operations RMAN> LIST INCARNATION OF DATABASE; List of Database Incarnations DB Key Inc Key DB Name DB ID STATUS Reset SCN Reset Time
Page 146 of 212
------- ------- -------- ---------------- -----1 2 1 2 RDBMS RDBMS 774627068 774627068 PARENT
---------- ---------1 21-OCT-06 21-OCT-06
CURRENT 173832
The preceding output indicates that a RESETLOGS was performed on database trgt a t SCN 164378, resulting in a new incarnation. The incarnation is distinguished by incarnation key (represented in the Inc Key column).
15.3.5 Listing Restore Points

You can use the LIST command to list either a specific restore point or all restore points known to the RMAN repository. The variations of the command are as follows: LIST RESTORE POINT restore_point_name; LIST RESTORE POINT ALL; RMAN indicates the SCN and time of the restore point, the type of restore point, and the name of the restore point. The following example shows sample output: RMAN> LIST RESTORE POINT ALL; using target database control file instead of recovery catalog SCN RSP Time Type Time Name
---------------- --------- ---------- --------- ---341859 343690 28-JUL-06 28-JUL-06 NORMAL_RS
28-JUL-06 GUARANTEED 28-JUL-06 GUARANTEED_RS
You can also see a list of the currently defined restore points by querying the V$RESTORE_POINT view as follows: SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE,STORAGE_SIZE FROM V$RESTORE_POINT;
You can view the name of each restore point, the SCN, wall-clock time and database incarnation number at which the restore points were created, whether each restore point is a guaranteed restore point, and how much space in the recovery area is being used for data needed for Flashback Database operations to that restore point. You can also use the following query to view only the guaranteed restore points: SELECT NAME, SCN, TIME, DATABASE_INCARNATION#, GUARANTEE_FLASHBACK_DATABASE, STORAGE_SIZE FROM V$RESTORE_POINT
WHERE GUARANTEE_FLASHBACK_DATABASE='YES'; For normal restore points, STORAGE_SIZE is zero. For guaranteed restore points, STORAGE_SIZE indicates the amount of disk space in the flash recovery area used to retain logs required to guarantee FLASHBACK DATABASE to that restore point.
15.3.6 Reporting on Backups and Database Schema

The RMAN REPORT command analyzes the available backups and your database. Which files have not been backed up recently? Reports enable you to confirm that your backup and recovery strategy is in fact meeting your requirements for database recoverability. The two major forms of REPORT used to determine whether your database is recoverable are:
Reporting on RMAN Operations REPORT NEED BACKUP Reports which database files need to be backed up to meet a configured or specified retention policy
Page 147 of 212
REPORT UNRECOVERABLE Reports which database files require backup because they have been affected by some NOLOGGING operation such as a direct-path INSERT The RMAN repository contains other information that you can access with the REPORT command. Table 103 summarizes the REPORT options. Table - REPORT Options
15.3.7. Reporting on Files Needing a Backup under a Retention Policy

Use the REPORT NEED BACKUP command to determine which database files need backup under a specific retention policy. With no arguments, REPORT NEED BACKUP reports which objects need backup under the currently configured retention policy. The output for a configured retention policy of REDUNDANCY 1 is similar to this example: RMAN> REPORT NEED BACKUP; RMAN retention policy will be applied to the command RMAN retention policy is set to redundancy 1 Report of files with less than 1 redundant backups File #bkps Name ---- ----- ----------------------------------------------------2 0 /oracle/oradata/trgt/undotbs01.dbf
Note: If you disable the retention policy using CONFIGURE RETENTION POLICY TO NONE, then REPORT NEED BACKUP returns an error message, because without a retention policy, RMAN cannot determine which files need to be backed up.
15.3.8. RMAN REPORT NEED BACKUP with Different Retention Policies

You can specify different criteria for REPORT NEED BACKUP, using one of the following forms of the command: REPORT NEED BACKUP RECOVERY WINDOW OF n DAYS Displays objects requiring backup to satisfy a recovery window-based retention policy. REPORT NEED BACKUP REDUNDANCY n Displays objects requiring backup to satisfy a redundancy-based retention policy. REPORT NEED BACKUP DAYS n Displays files that require more than n days' worth of archived redo log files for recovery. REPORT NEED BACKUP INCREMENTAL n Displays files that require application of more than n incremental backups for recovery.
Page 148 of 212
15.3.9. Using RMAN REPORT NEED BACKUP with Tablespaces and Datafiles
REPORT NEED BACKUP can check the entire database, skip specified tablespaces, or check only specific tablespaces or datafiles against different retention policies, as shown in the following examples: REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE SKIP TABLESPACE TBS_2; REPORT NEED BACKUP REDUNDANCY 2 DATAFILE 1; REPORT NEED BACKUP TABLESPACE TBS_3; # uses configured retention policy REPORT NEED BACKUP INCREMENTAL 2; # checks entire database
15.3.10. Using REPORT NEED BACKUP with Backups on Tape or Disk Only
You can limit the backups tested by REPORT NEED BACKUP to disk-based or tape-based backups only, as shown in these examples: REPORT NEED BACKUP RECOVERY WINDOW OF 2 DAYS DATABASE DEVICE TYPE sbt; REPORT NEED BACKUP DEVICE TYPE DISK; REPORT NEED BACKUP TABLESPACE TBS_3 DEVICE TYPE sbt;
15.3.11. Reporting on Datafiles Affected by Unrecoverable Operations

When a datafile has been changed by an unrecoverable operation, such as a direct load insert, normal media recovery cannot be used to recover the file, because an unrecoverable operation does not generate redo. You must perform either a full or incremental backup of affected datafiles after such operations, to ensure that data blocks affected by the unrecoverable operation can be recovered using RMAN. To identify datafiles affected by an unrecoverable operation: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Execute the REPORT UNRECOVERABLE command. The following example includes sample output: RMAN> REPORT UNRECOVERABLE; Report of files that need backup due to unrecoverable operations File Type of Backup Required Name ---- ----------------------- ----------------------------------1 full /oracle/oradata/trgt/system01.dbf
15.3.12. Reporting on Obsolete Backups

You can report backup sets, backup pieces and datafile copies that are obsolete, that is, not needed to meet a specified retention policy, by specifying the OBSOLETE keyword. To report obsolete backups: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Execute the CROSSCHECK command to update the status of backups in the repository compared to their status on disk. In the simplest case, you could crosscheck all backups on disk, tape or both, using any one of the following commands: CROSSCHECK BACKUP DEVICE TYPE DISK; CROSSCHECK BACKUP DEVICE TYPE sbt; CROSSCHECK BACKUP; # crosshecks all backups on all devices 3. Run REPORT OBSOLETE to identify which backups are obsolete because they are no longer needed for recovery. If you do not specify any other options, then REPORT OBSOLETE displays the backups that are obsolete according to the current retention policy, as shown in the following example: RMAN> REPORT OBSOLETE;
Reporting on RMAN Operations Datafile Copy Datafile Copy Datafile Copy Backup Set Backup Piece . . . 44 45 46 26 26 08-FEB-06 08-FEB-06 08-FEB-06 08-FEB-06 08-FEB-06
Page 149 of 212 /backup/ora_df549738566_s70_s1 /backup/ora_df549738567_s71_s1 /backup/ora_df549738568_s72_s1
/backup/ora_df549738682_s76_s1
You can also check which backups are obsolete under different recovery window-based or redundancy-based retention policies, by using REPORT OBSOLETE with RECOVERY WINDOW and REDUNDANCY options, as shown in these examples: REPORT OBSOLETE RECOVERY WINDOW OF 3 DAYS; REPORT OBSOLETE REDUNDANCY 1;
15.3.13. Reporting on the Database Schema

The REPORT SCHEMA command lists and displays information about the database files, tablespaces, and so on. If you do not specify FOR DB_UNIQUE_NAME with REPORT SCHEMA, then a recovery catalog connection is optional, but a target database connection is required. In a Data Guard environment, you can specify REPORT SCHEMA FOR DB_UNIQUE_NAME to report the schema for a database in the environment. In this case, an RMAN connection to a target database is not required. You can connect RMAN to the recovery catalog and set the DBID instead. To report on the database schema: 1. Start RMAN and connect to the desired databases. 2. If you did not connect RMAN to a target database in the previous step, and you intend to specify the FOR DB_UNIQUE_NAME clause on REPORT SCHEMA, then set the database DBID. For example, enter the following command: RMAN> SET DBID 28014364; 3. Run the REPORT SCHEMA command as shown in the following example: RMAN> REPORT SCHEMA; Report of database schema for database with db_unique_name DGRDBMS List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- -----------------------1 2 3 4 5 450 141 50 50 50 SYSTEM SYSAUX UD1 TBS_11 TBS_11 YES NO YES NO NO /disk1/oracle/dbs/t_db1.f /disk1/oracle/dbs/t_ax1.f /disk1/oracle/dbs/t_undo1.f /disk1/oracle/dbs/tbs_111.f /disk1/oracle/dbs/tbs_112.f
List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- -------------------1 40 TEMP 32767 /disk1/oracle/dbs/t_tmp1.f
Page 150 of 212
If you use a recovery catalog, then you can use the atClause to specify a past time, SCN, or log sequence number, as shown in these examples of the command: RMAN> REPORT SCHEMA AT TIME 'SYSDATE-14'; # schema 14 days ago RMAN> REPORT SCHEMA AT SCN 1000; # schema at scn 1000
RMAN> REPORT SCHEMA AT SEQUENCE 100 THREAD 1; # schema at sequence 100 RMAN> REPORT SCHEMA FOR DB_UNIQUE_NAME standby1; # schema for database standby1
15.4 Using V$ Views to Query Backup Metadata

In some cases, V$ views supply information that is not available through use of the LIST and REPORT commands. This section describes cases in which V$ views are particularly useful.
15.4.1 Querying Details of Past and Current RMAN Jobs

An RMAN job is the set of commands executed within an RMAN session. Thus, one RMAN job can contain multiple commands. For example, you may execute two separate BACKUP commands and a RECOVER COPY command in a single session. An RMAN backup job is the set of BACKUP commands executed in one RMAN job. For example, a BACKUP DATABASE and BACKUP ARCHIVELOG ALL command executed in the same RMAN job make up a single RMAN backup job. The views V$RMAN_BACKUP_JOB_DETAILS and V$RMAN_BACKUP_SUBJOB_DETAILS and their corresponding recovery catalog versions provide details on RMAN backup jobs. For example, the views show how long a backup took, how many backup jobs have been issued, the status of each backup job (for example, whether it failed or completed), when a job started and finished, and what type of backup was performed. The SESSION_KEY column is the unique key for the RMAN session in which the backup job occurred.Note that RMAN backups often write less than they read. Because of RMAN compression, the OUTPUT_BYTES_PER_SEC column cannot be used as measurement of backup speed. The appropriate column to measure backup speed is INPUT_BYTES_PER_SEC. The ratio between read and written data is described in the COMPRESSION_RATIO column. To query details about past and current RMAN jobs: 1. Connect SQL*Plus to the database whose backup history you intend to query. 2. Query the V$RMAN_BACKUP_JOB_DETAILS view for information about the backup type, status, and start and end time. The following query shows the backup job history ordered by session key, which is the primary key for the RMAN session: COL STATUS FORMAT a9 COL hrs FORMAT 999.99
SELECT SESSION_KEY, INPUT_TYPE, STATUS, TO_CHAR(START_TIME,'mm/dd/yy hh24:mi') start_time, TO_CHAR(END_TIME,'mm/dd/yy hh24:mi') ELAPSED_SECONDS/3600 FROM V$RMAN_BACKUP_JOB_DETAILS ORDER BY SESSION_KEY; end_time, hrs
The following sample output shows the backup job history: SESSION_KEY INPUT_TYPE STATUS START_TIME END_TIME HRS
----------- ------------- --------- -------------- -------------- ------9 DATAFILE FULL COMPLETED 04/18/07 18:14 04/18/07 18:15 16 DB FULL 113 ARCHIVELOG COMPLETED 04/18/07 18:20 04/18/07 18:22 COMPLETED 04/23/07 16:04 04/23/07 16:05 .02 .03 .01
3. Query the V$RMAN_BACKUP_JOB_DETAILS view for the rate of backup jobs in an RMAN session.
Page 151 of 212
The following query shows the backup job speed ordered by session key, which the primary key for the RMAN session. The columns in_sec and out_sec columns display the data input and output per second. COL in_sec FORMAT a10 COL out_sec FORMAT a10 COL TIME_TAKEN_DISPLAY FORMAT a10 SELECT SESSION_KEY, OPTIMIZED, COMPRESSION_RATIO, INPUT_BYTES_PER_SEC_DISPLAY in_sec, OUTPUT_BYTES_PER_SEC_DISPLAY out_sec, TIME_TAKEN_DISPLAY FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY; The following sample output shows the speed of the backup jobs: SESSION_KEY OPT COMPRESSION_RATIO IN_SEC OUT_SEC
TIME_TAKEN
----------- --- ----------------- ---------- ---------- ---------9 NO 16 NO 113 NO 1 1.32732239 1 8.24M 6.77M 2.99M 8.24M 5.10M 2.99M 00:01:14 00:01:45 00:00:44
4. Query the V$RMAN_BACKUP_JOB_DETAILS view for the size of the backups in an RMAN session. If you run BACKUP DATABASE, then V$RMAN_BACKUP_JOB_DETAILS.OUTPUT_BYTES shows the total size of backup sets written by the backup job for the database that you are backing up. To view backup set sizes for all registered databases, query RC_RMAN_BACKUP_JOB_DETAILS. The following query shows the backup job speed ordered by session key, which the primary key for the RMAN session. The columns in_sec and out_sec columns display the data input and output per second. COL in_size FORMAT a10 COL out_size FORMAT a10 SELECT SESSION_KEY, INPUT_TYPE, COMPRESSION_RATIO, INPUT_BYTES_DISPLAY in_size, OUTPUT_BYTES_DISPLAY out_size FROM V$RMAN_BACKUP_JOB_DETAILS
ORDER BY SESSION_KEY; The following sample output shows the speed of the backup jobs: SESSION_KEY INPUT_TYPE COMPRESSION_RATIO IN_SIZE
OUT_SIZE
----------- ------------- ----------------- ---------- ---------10 DATAFILE FULL 17 DB FULL 1 1.13736669 602.50M 634.80M 602.58M 558.13M
15.4.2 Querying Recovery Catalog Views

The LIST, REPORT, and SHOW commands provide the easiest means of accessing the data in the control file and the recovery catalog. Nevertheless, you can sometimes also obtain useful information from the recovery catalog views, which reside in the recovery catalog schema and use the RC_ prefix.
Page 152 of 212
About Recovery Catalog Views RMAN obtains backup and recovery metadata from a target database control file and stores it in the tables of the recovery catalog. The recovery catalog views are derived from these tables. Note that the recovery catalog views are not normalized or optimized for user queries. In general, the recovery catalog views are not as user-friendly as the RMAN reporting commands. For example, when you start RMAN and connect to a target database, you obtain the information for this target database only when you issue LIST, REPORT, and SHOW commands. If you have ten different target databases registered in the same recovery catalog, then any query of the catalog views show the metadata for all incarnations of all ten databases. You often have to perform complex selects and joins among the views to extract usable information about a database incarnation. Most of the catalog views have a corresponding V$ view in the database. For example, RC_BACKUP_PIECE corresponds to V$BACKUP_PIECE. The primary difference between the recovery catalog view and corresponding V$ view is that each recovery catalog view contains metadata about all the target databases registered in the recovery catalog. The V$ view contains information only about itself.
Page 153 of 212
16. Managing a Recovery Catalog

16.1 Purpose of the Recovery Catalog
A recovery catalog is a database schema used by RMAN to store metadata about one or more Oracle databases. Typically, you store the catalog in a dedicated database. A recovery catalog provides the following benefits: A recovery catalog creates redundancy for the RMAN repository stored in the control file of each target database. The recovery catalog serves as a secondary metadata repository. If the target control file and all backups are lost, then the RMAN metadata still exists in the recovery catalog. A recovery catalog centralizes metadata for all your target databases. Storing the metadata in a single place makes reporting and administration tasks easier to perform. A recovery catalog can store metadata history much longer than the control file. This situation can be a problem if you have to do a recovery that goes further back in time than the history in the control file. The added complexity of managing a recovery catalog database can be offset by the convenience of having the extended backup history available. Some RMAN features function only when you use a recovery catalog. For example, you can store RMAN scripts in a recovery catalog. The chief advantage of a stored script is that it is available to any RMAN client that can connect to the target database and recovery catalog. Command files are only available if the RMAN client has access to the file system on which they are stored. A recovery catalog is required when you use RMAN in a Data Guard environment. By storing backup metadata for all primary and standby databases, the catalog enables you to offload backup tasks to one standby database while enabling you to restore backups on other databases in the environment.
16.2 Basic Concepts for the Recovery Catalog

The recovery catalog contains metadata about RMAN operations for each registered target database. When RMAN is connected to a recovery catalog, RMAN obtains its metadata exclusively from the catalog. The catalog includes the following types of metadata: Datafile and archived redo log backup sets and backup pieces Datafile copies Archived redo logs and their copies Database structure (tablespaces and datafiles) Stored scripts, which are named user-created sequences of RMAN commands Persistent RMAN configuration settings
16.3 Database Registration

The enrolling of a database in a recovery catalog for RMAN use is called registration. The recommended practice is to register every target database in your environment a single recovery catalog. For example, you can register databases prod1, prod2, and prod3 in a single catalog owned by catowner in the database catdb.
16.4 Centralization of Metadata in a Base Recovery Catalog

The owner of a centralized recovery catalog, which is also called the base recovery catalog, can grant or revoke restricted access to the catalog to other database users. Each restricted user has full read/write access to his own metadata, which is called a virtual private catalog. The RMAN metadata is stored in the schema of the virtual private
Page 154 of 212
catalog owner. The owner of the base recovery catalog determines which objects each virtual catalog user can access. You can use a recovery catalog in an environment in which you use or have used different versions of Oracle Database. As a result, your environment can have different versions of the RMAN client, recovery catalog database, recovery catalog schema, and target database.
16.5 Recovery Catalog Resynchronization

For RMAN operations such as backup, restore, and crosscheck, RMAN always first updates the control file and then propagates the metadata to the recovery catalog. This flow of metadata from the mounted control file to the recovery catalog, which is known as recovery catalog resynchronization, ensures that the metadata that RMAN obtains from the control file is current.
16.6 Stored Scripts

You can use a stored script as an alternative to a command file for managing frequently used sequences of RMAN commands. The script is stored in the recovery catalog rather than on the file system. A local stored script is associated with the target database to which RMAN is connected when the script is created, and can only be executed when you are connected to this target database. A global stored script can be run against any database registered in the recovery catalog. A virtual private catalog user has read-only access to global scripts. Creating or updating global scripts must be done while connected to the base recovery catalog.
16.7 Planning the Size of the Recovery Catalog Schema

You must allocate space to be used by the catalog schema. The size of the recovery catalog schema depends upon the number of databases monitored by the catalog. The schema also grows as the number of archived redo log files and backups for each database increases. Finally, if you use RMAN stored scripts stored in the catalog, some space must be allocated for those scripts. For an example, assume that the trgt database has 100 files and you back up the database once a day, producing 50 backup sets containing 1 backup pieces each. If you assume that each row in the backup piece table uses the maximum amount of space, then one daily backup will consume less than 170 KB in the recovery catalog. So, if you back up once a day for a year, then the total storage in this period is about 62 MB. Assume approximately the same amount for archived logs. Thus, the worst case is about 120 MB for a year for metadata storage. For a more typical case in which only a portion of the backup piece row space is used, 15 MB for each year is realistic. If you plan to register multiple databases in your recovery catalog, then remember to add up the space required for each one based on the previous calculation to arrive at a total size for the default tablespace of the recovery catalog schema.
16.8 Allocating Disk Space for the Recovery Catalog Database

If you are creating your recovery catalog in an existing database, then add enough room to hold the default tablespace to the recovery catalog schema. If you are creating a new database to hold your recovery catalog, then in addition to the space for the recovery catalog schema itself, allow space for other files in the recovery catalog database: SYSTEM and SYSAUX tablespaces Temporary tablespaces Undo tablespaces Online redo log files
Most of the space used in the recovery catalog database is devoted to supporting tablespaces, for example, the SYSTEM, temporary, and undo tablespaces.
Page 155 of 212
Caution: Ensure that the recovery catalog and target databases do not reside on the same disk. If both your recovery catalog and your target database suffer hard disk failure, then your recovery process is much more difficult. If possible, take other measures as well to eliminate common points of failure between your recovery catalog database and the databases you are backing up.
16.9 Creating the Recovery Catalog Schema Owner

After choosing the recovery catalog database and creating necessary space, you are ready to create the owner of the recovery catalog and grant this user necessary privilege. Assume the following background information for the instructions in the following sections: User SYS has SYSDBA privileges on the recovery catalog database catdb. A tablespace called tools in the recovery catalog database catdb stores the recovery catalog. Note that to use an RMAN reserved word as a tablespace name, you must enclose it in quotes and put it in uppercase. A tablespace called temp exists in the recovery catalog database.
To create the recovery catalog schema in the recovery catalog database: 1. Start SQL*Plus and connect with administrator privileges to the database containing the recovery catalog. In this example, the database is catdb. 2. Create a user and schema for the recovery catalog. For example, you could enter the following SQL statement (replacing password with a user-defined password): CREATE USER rman IDENTIFIED BY password TEMPORARY TABLESPACE temp DEFAULT TABLESPACE tools QUOTA UNLIMITED ON tools; 3. Grant the RECOVERY_CATALOG_OWNER role to the schema owner. This role provides the user with all privileges required to maintain and query the recovery catalog. GRANT RECOVERY_CATALOG_OWNER TO rman;
16.9.1 Executing the CREATE CATALOG Command

After creating the catalog owner, create the catalog tables with the RMAN CREATE CATALOG command. The command creates the catalog in the default tablespace of the catalog owner. To create the recovery catalog: 1. Start RMAN and connect to the database that will contain the catalog. Connect to the database as the recovery catalog owner. 2. Run the CREATE CATALOG command to create the catalog. The creation of the catalog can take several minutes. If the catalog tablespace is this user's default tablespace, then you can run the following command: RMAN> CREATE CATALOG; You can specify the tablespace name for the catalog in the CREATE CATALOG command. For example: RMAN> CREATE CATALOG TABLESPACE cat_tbs; Note: If the tablespace name you wish to use for the recovery catalog is an RMAN reserved word, then it must be uppercase and enclosed in quotes. For example: CREATE CATALOG TABLESPACE 'CATALOG'; 3. You can check the results by using SQL*Plus to query the recovery catalog to see which tables were created: SQL> SELECT TABLE_NAME FROM USER_TABLES;
16.10 Registering a Database in the Recovery Catalog

This section describes how to maintain target database records in the recovery catalog.
Page 156 of 212
16.10.1 Registering a Database with the REGISTER DATABASE Command

The first step in using a recovery catalog with a target database is registering the target database in the recovery catalog. If you use the catalog in a Data Guard environment, then you can only register the primary database in this way. Use the following procedure: 1. Start RMAN and connect to a target databa se and recovery catalog. The recovery catalog database must be open. For example, issue the following to connect to the catalog database with the net service name catdb as user rman (who owns the catalog schema): % rman TARGET / CATALOG rman@catdb 2. If the target database is not mounted, then mount or open it: STARTUP MOUNT; 3. Register the target database in the connected recovery catalog: REGISTER DATABASE; RMAN creates rows in the catalog tables to contain information about the target database, then copies all pertinent data about the target database from the control file into the catalog, synchronizing the catalog with the control file. 4. Verify that the registration was successful by running REPORT SCHEMA: REPORT SCHEMA; Report of database schema File Size(MB) Tablespace RB segs Datafile Name
---- ---------- ---------------- ------- ------------------1 2 3 4 5 6 7 8 307200 SYSTEM 20480 UNDOTBS 10240 CWMLITE 10240 DRSYS 10240 EXAMPLE 10240 INDX 10240 TOOLS 10240 USERS NO YES NO NO NO NO NO NO /oracle/oradata/trgt/system01.dbf /oracle/oradata/trgt/undotbs01.dbf /oracle/oradata/trgt/cwmlite01.dbf /oracle/oradata/trgt/drsys01.dbf /oracle/oradata/trgt/example01.dbf /oracle/oradata/trgt/indx01.dbf /oracle/oradata/trgt/tools01.dbf /oracle/oradata/trgt/users01.dbf
16.11 Cataloging Backups in the Recovery Catalog

If you have datafile copies, backup pieces, or archived logs on disk, then you can catalog them in the recovery catalog with the CATALOG command. When using a recovery catalog, cataloging older backups that have aged out of the control file lets RMAN use the older backups during restore operations. The following commands illustrate this technique: CATALOG DATAFILECOPY '/disk1/old_datafiles/01_01_2003/users01.dbf'; CATALOG ARCHIVELOG '/disk1/arch_logs/archive1_731.dbf', '/disk1/arch_logs/archive1_732.dbf'; CATALOG BACKUPPIECE '/disk1/backups/backup_820.bkp'; You can also catalog multiple backup files in a directory at once by using the CATALOG START WITH command, as shown in the following example: CATALOG START WITH '/disk1/backups/'; RMAN lists the files to be added to the RMAN repository and prompts for confirmation before adding the backups. Be careful when creating your prefix with CATALOG START WITH. RMAN scans all paths for all files on disk which begin with the specified prefix. The prefix is not just a directory name. Using the wrong prefix can cause the cataloging of the wrong set of files.
Page 157 of 212
For example, assume that a group of directories /disk1/backups, /disk1/backups-year2003, /disk1/backupsets, and /disk1/backupsets/test and so on, all contain backup files. The following command catalogs all files in all of these directories, because /disk1/backups is a prefix for the paths for all of these directories: CATALOG START WITH '/disk1/backups'; To catalog only backups in the /disk1/backups directory, the correct command would be as follows: CATALOG START WITH '/disk1/backups/';
16.12 Creating and Managing Virtual Private Catalogs

The recommended practice is to create one recovery catalog that serves as the central RMAN repository for all your databases. The recovery catalog as a whole is also termed the base recovery catalog. This base catalog can contain zero or more virtual private catalogs. A virtual private catalog is a set of synonyms and views that refer to a base recovery catalog.
16.12.1 About Virtual Private Catalogs

By default, only the owner of a base recovery catalog has access to its metadata. As the owner of a base recovery catalog, you can use the RMAN GRANT command to grant restricted access to the recovery catalog to other database users. The owner of the base recovery catalog decides which database users can share a recovery catalog and which databases they can access. When you grant a catalog user restricted access, you give this user full read/write access to his own RMAN metadata, which is the virtual private catalog. Note that a virtual private catalog owner can create a local stored script, but only has read-only access to a global stored script. The set of views and synonyms that makes up the virtual private catalog is stored in the schema of the virtual catalog owner. The mechanisms for virtual private catalogs exist in the recovery catalog schema itself. Security is provided by the recovery catalog database, not by the RMAN executable. The basic steps for creating a virtual catalog are as follows: 1. Create the database user who will own the virtual catalog (if this user does not already exist) and grant this user access privileges. 2. Create the virtual private catalog. After the virtual private catalog is created, you can revoke catalog access privileges as necessary. Note that if the recovery catalog is a virtual catalog, then the RMAN client connecting to it must be at patch level 10.1.0.6 or 10.2.0.3. Oracle9i RMAN clients cannot connect to a virtual private catalog. This version restriction does not affect RMAN client connections to an Oracle Database 11g base recovery catalog, even if the base catalog has some virtual private catalog users.
16.12.2 Creating and Granting Privileges to a Virtual Private Catalog Owner

This section assumes that you have already created a base recovery catalog and are the owner of this recovery catalog. Assume that the following databases are registered in the base recovery catalog: prod1, prod2, and prod3. The database user who owns the base recovery catalog is catowner. You want to create database user vpc1 and grant this user access privileges only to prod1 and prod2. By default, a virtual private catalog owner has no access to the base recovery catalog.To create and grant privileges to a virtual private catalog owner: 1. Start SQL*Plus and connect to the recovery catalog database with administrator privileges. 2. If the user that will own the virtual catalog is not yet created, then create the user. For example, if you want to create database user vpc1 to own the catalog, then you could execute the following command (replacing password with a user-defined password): SQL> CREATE USER vpc1 IDENTIFIED BY password 2 3 DEFAULT TABLESPACE vpcusers QUOTA UNLIMITED ON vpcusers;
Page 158 of 212
3. Grant the RECOVERY_CATALOG_OWNER role to the database user that will own the virtual catalog, and then exit SQL*Plus. The following example grants the role to user vpc1: SQL> GRANT recovery_catalog_owner TO vpc1; SQL> EXIT; 4. Start RMAN and connect to the recovery catalog database as the base recovery catalog owner (not the virtual catalog owner). The following example connects to the base recovery catalog as catowner: % rman RMAN> CONNECT CATALOG catowner@catdb;
recovery catalog database Password: password connected to recovery catalog database 5. Grant desired privileges to the virtual catalog owner. The following example gives user vpc1 access to the metadata for prod1 and prod2 (but not prod3): RMAN> GRANT CATALOG FOR DATABASE prod1 TO vpc1; RMAN> GRANT CATALOG FOR DATABASE prod2 TO vpc1; You can also use a DBID rather than a database name. Note that the virtual catalog user does not have access to the metadata for any other databases registered in the recovery catalog. You can also grant the user the ability to register new target databases in the recovery catalog. For example: RMAN> GRANT REGISTER DATABASE TO vpc1;
16.12.3 Creating a Virtual Private Catalog

This section assumes that the virtual catalog owner has been given the RECOVERY_CATALOG_OWNER database role. Also, the base catalog owner used the GRANT command to give the virtual catalog owner access to metadata in the base recovery catalog.To create a virtual private catalog: 1. Start RMAN and connect to the recovery catalog database as the virtual recovery catalog owner (not the base catalog owner). The following example connects to the recovery catalog as vpc1: % rman RMAN> CONNECT CATALOG vpc1@catdb; 2. Create the virtual catalog. The following command creates the virtual catalog: CREATE VIRTUAL CATALOG; 3. If you intend to use a 10.2 or earlier release of RMAN with this virtual catalog, then execute the following PL/SQL procedure (where base_catalog_owner is the database user who owns the base recovery catalog): base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG
16.12.4 Revoking Privileges from a Virtual Private Catalog Owner

This section assumes that you have already created a virtual recovery catalog. Assume that two databases are registered in the base recovery catalog: prod1 and prod2. As owner of the base catalog, you have granted the vpc1 user access privileges to prod1. You have also granted this user the right to register databases in his virtual private catalog. Now you want to revoke privileges from vpc1.To revoke privileges from a virtual catalog owner: 1. Start RMAN and connect to the recovery catalog database as the recovery catalog owner (not the virtual catalog owner). The following example connects to the recovery catalog as catowner: % rman RMAN> CONNECT CATALOG catowner@catdb;
Reporting on RMAN Operations 2. Revoke specified privileges from the virtual catalog owner. The following command revokes access to the metadata for prod1 from virtual catalog owner vpc1: REVOKE CATALOG FOR DATABASE prod1 FROM vpc1;
Page 159 of 212
You can also specify a DBID rather than a database name. Note that vpc1 retains all other granted catalog privileges. You can also revoke the privilege to register new target databases in the recovery catalog. For example: REVOKE REGISTER DATABASE FROM vpc1;
16.12.5. Dropping a Virtual Private Catalog

This section assumes that you have already created a virtual recovery catalog and now want to drop the virtual catalog. When you drop a virtual private catalog, you do not remove the base recovery catalog itself, but only drop the synonyms and views that refer to the base recovery catalog.To drop a virtual private catalog: 1. Start RMAN and connect to the recovery catalog database as the virtual catalog owner (not the base catalog owner). The following example connects to the recovery catalog as user vpc1: % rman RMAN> CONNECT CATALOG vpc1@catdb; 2. Drop the catalog. If you are using an Oracle Database 11g or later RMAN executable, then drop the virtual private catalog with the DROP CATALOG command: DROP CATALOG; If you are using an Oracle Database 10g or earlier RMAN executable, then you cannot use the DROP CATALOG command. Instead, connect SQL*Plus to the catalog database as the virtual catalog user, then execute the following PL/SQL procedure (where base_catalog_owner is the database user who owns the base recovery catalog): base_catalog_owner.DBMS_RCVCAT.CREATE_VIRTUAL_CATALOG
16.12.6. Protecting the Recovery Catalog

Include the recovery catalog database in your backup and recovery strategy. If you do not back up the recovery catalog and a disk failure occurs that destroys the recovery catalog database, then you may lose the metadata in the catalog. Without the recovery catalog contents, recovery of your other databases is likely to be more difficult.
16.12.7 Backing up the Recovery Catalog

A single recovery catalog is able to store metadata for multiple target databases. Consequently, loss of the recovery catalog can be disastrous. You should back up the recovery catalog frequently. This section provides general guidelines for developing a strategy for protecting the recovery catalog. Backing up the Recovery Catalog Frequently The recovery catalog database is a database like any other, and is also a key part of your backup and recovery strategy. Protect the recovery catalog as you would protect any other part of your database, by backing it up. The backup strategy for your recovery catalog database should be part of your overall backup and recovery strategy. Back up the recovery catalog with the same frequency that you back up a target database. For example, if you make a weekly whole database backup of a target database, then back up the recovery catalog after the backup of the target database. This backup of the recovery catalog can help you in a disaster recovery scenario. Even if you have to restore the recovery catalog database with a control file autobackup, you can use the full record of backups in your restored recovery catalog database to restore the target database. Follow these guidelines when developing an RMAN backup strategy for the recovery catalog database: Run the recovery catalog database in ARCHIVELOG mode so that you can do point-in-time recovery if needed. Set the retention policy to a REDUNDANCY value greater than 1. Back up the database to two separate media (for example, disk and tape). Run BACKUP DATABASE PLUS ARCHIVELOG at regular intervals, to a media manager if available, or just
Reporting on RMAN Operations to disk. Do not use another recovery catalog as the repository for the backups. Configure the control file autobackup feature to ON.
Page 160 of 212
With this strategy, the control file autobackup feature ensures that the recovery catalog database can always be recovered, so long as the control file autobackup is available.
16.12.7 Separating the Recovery Catalog from the Target Database

A recovery catalog is only effective when separated from the data that it is designed to protect. Thus, you should never store a recovery catalog containing the RMAN repository for a database in the same database as the target database. Also, do not store the catalog database on the same disks as the target database.To illustrate why data separation is advised, assume that you store the catalog for database prod1 in prod1. If prod1 suffers a total media failure, and if the recovery catalog for prod1 is also stored in prod1, then if you lose the database you also lose the recovery catalog. At this point the only option is to restore an autobackup of the control file for prod1 and use it to restore and recover the database without the benefit of any information stored in the recovery catalog.
16.12.8 Exporting the Recovery Catalog Data for Logical Backups

Logical backups of the RMAN recovery catalog created with the Data Pump Export utility can be a useful supplement for physical backups. In the event of damage to a recovery catalog database, you can use Data Pump Import to quickly reimport the exported recovery catalog data into another database and rebuild the catalog.
16.12.9 Recovering the Recovery Catalog

Restoring and recovering the recovery catalog database is much like restoring and recovering any other database with RMAN. You can restore the control file and server parameter file for the recovery catalog database from an autobackup, then restore and perform complete recovery on the rest of the database. If you are in a situation where you are using multiple recovery catalogs, then you can also use another recovery catalog to record metadata about backups of this recovery catalog database. If recovery of the recovery catalog database through the normal Oracle recovery procedures is not possible, then you must re-create the catalog. Examples of this worst-case scenario include: A recovery catalog database that has never been backed up A recovery catalog database that has been backed up, but cannot be recovered because the datafile backups or archived logs are not available You have the following options for partially re-creating the contents of the missing recovery catalog: Use the RESYNC CATALOG command to update the recovery catalog with any RMAN repository information from the control file of the target database or a controlfile copy. Note that any metadata from control file records that aged out of the control file is lost. Issue CATALOG START WITH... commands to recatalog any available backups. To minimize the likelihood of this worst-case scenario, your backup strategy should at least include backing up the recovery catalog.
16.13 Managing Stored Scripts

You can store scripts in the recovery catalog. This section explains how to create and manage stored scripts.
16.13.1 About Stored Scripts

You can use a stored script as an alternative to a command file for managing frequently used sequences of RMAN commands. The script is stored in the recovery catalog rather than on the file system. Stored scripts can be local or global. A local script is associated with the target database to which RMAN is connected when the script is created, and can only be executed when you are connected to that target database. A global stored script can be run against
Page 161 of 212
any database registered in the recovery catalog, if the RMAN client is connected to the recovery catalog and a target database. The commands allowable within the brackets of the CREATE SCRIPT command are the same commands supported within a RUN block. Any command that is legal within a RUN command is permitted in the stored script. The following commands are not legal within stored scripts: RUN, @, and @@. When specifying a script name, RMAN permits but generally does not require that you u se quotes around the name of a stored script. If the name begins with a digit or is an RMAN reserved word, however, then you must put quotes around the name to use it as a stored script name. Consider avoiding stored script names that begin with nonalphabetic characters or that are the same as RMAN reserved words. Consider using a naming convention to avoid confusion between global and local stored scripts. For the EXECUTE SCRIPT, DELETE SCRIPT and PRINT SCRIPT commands, if the script name passed as an argument is not the name of a script defined for the connected target instance, then RMAN looks for a global script by the same name. For example, if the global script global_backup is in the recovery catalog, but no local stored script global_backup is defined for the target database, then the following command deletes the global script: DELETE SCRIPT global_backup; Note that to use commands related to stored scripts, even global scripts, you must be connected to both a recovery catalog and a target database instance.
16.13.2 Creating Stored Scripts

You can use the CREATE SCRIPT command to create a stored script. If GLOBAL is specified, then a global script with this name must not already exist in the recovery catalog. If GLOBAL is not specified, then a local script must not already exist with the same name for the same target database. Note that you can also use the REPLACE SCRIPT to create a new script or update an existing script. To create a stored script: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Run the CREATE SCRIPT command. The following example illustrates creation of a local script: CREATE SCRIPT full_backup { BACKUP DATABASE PLUS ARCHIVELOG; DELETE OBSOLETE; } For a global script, the syntax is similar: CREATE GLOBAL SCRIPT global_full_backup { BACKUP DATABASE PLUS ARCHIVELOG; DELETE OBSOLETE; } Optionally, you can provide a COMMENT with descriptive information: CREATE GLOBAL SCRIPT global_full_backup COMMENT 'use only with ARCHIVELOG mode databases' { BACKUP DATABASE PLUS ARCHIVELOG; DELETE OBSOLETE; } You can also create a script by reading its contents from a text file. The file must begin with a left brace ({) character, contain a series of commands valid within a RUN block, and end with a right brace (}) character. Otherwise, a syntax error is signalled, just as if the commands were entered at the keyboard.
Reporting on RMAN Operations CREATE SCRIPT full_backup FROM FILE '/tmp/my_script_file.txt';
Page 162 of 212
3. Examine the output. If no errors are displayed, then RMAN successfully created the script and stored in the recovery catalog.
16.13.3 Replacing Stored Scripts

To update stored scripts, use the REPLACE SCRIPT command. If you are replacing a local script, then you must be connected to the target database that you connected to when you created the script. If the script does not already exist, then RMAN creates it.To replace a stored script: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Execute REPLACE SCRIPT. This following example updates the script full_backup with new contents: REPLACE SCRIPT full_backup { BACKUP DATABASE PLUS ARCHIVELOG; } You can update global scripts by specifying the GLOBAL keyword as follows: REPLACE GLOBAL SCRIPT global_full_backup COMMENT 'A script for full backup to be used with any database' { BACKUP AS BACKUPSET DATABASE PLUS ARCHIVELOG; } As with CREATE SCRIPT, you can update a local or global stored script from a text file with the following form of the command: REPLACE GLOBAL SCRIPT global_full_backup FROM FILE /tmp/my_script_file.txt';
16.13.4 Executing Stored Scripts

Use the EXECUTE SCRIPT command to run a stored script. If GLOBAL is specified, then a global script with this name must already exist in the recovery catalog; otherwise, RMAN returns error RMAN-06004. If GLOBAL is not specified, then RMAN searches for a local stored script defined for the current target database. If no local script with this name is found, then RMAN searches for a global script by the same name and executes it if one is found. To execute a stored script: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. If needed, use SHOW to examine your configured channels. Your script will use the automatic channels configured at the time you execute the script. Use ALLOCATE CHANNEL commands in the script if you need to override the configured channels. Because of the RUN block, if a n RMAN command in the script fails, subsequent RMAN commands in the script will not execute. 3. Run EXECUTE SCRIPT. This command requires a RUN block, as shown in the following example: RUN { EXECUTE SCRIPT full_backup; } The preceding command invokes a local script if one is with the name specified. If no local script is found, but there is a global script with the name specified, then RMAN executes the global script. You can also use EXECUTE GLOBAL SCRIPT to control which script is invoked if a local and a global script have the same name. If there is no local script called global_full_backup, the following two commands have the same effect: RUN
Reporting on RMAN Operations { EXECUTE GLOBAL SCRIPT global_full_backup; }
Page 163 of 212
RUN { EXECUTE SCRIPT global_full_backup; }
16.13.5 Creating and Executing Dynamic Stored Scripts

You can specify substitution variables in the CREATE SCRIPT command. When you start RMAN on the command line, the USING clause specifies one or more values for use in substitution variables in a command file. As in SQL*Plus, &1 indicates where to place the first value, &2 indicates where to place the second value, and so on. To create and use a dynamic stored script: 1. Create a command file that contains a CREATE SCRIPT statement with substitution variables for values that must be dynamically updated. The following example shows the content of command file /tmp/catscript.rman. The script uses substitution variables for the name of the tape set, for a string in the FORMAT specification, and for the name of the restore point. CREATE SCRIPT quarterly { ALLOCATE CHANNEL c1 DEVICE TYPE sbt PARMS 'ENV=(OB_MEDIA_FAMILY=&1)'; BACKUP TAG &2 FORMAT '/disk2/bck/&1%U.bck' KEEP FOREVER RESTORE POINT &3 DATABASE; } 2. Connect RMAN to a target database (which must be mounted or open) and recovery catalog, specifying the initial values for the recovery catalog script. For example, enter the following command: % rman TARGET / CATALOG rman@catdb USING arc_backup bck0906 FY06Q3 A recovery catalog is required for KEEP FOREVER, but is not required for any other KEEP option. 3. Run the command file created in the first step to create the stored script. For example, run the /tmp/catscript.rman command file as follows: RMAN> @/tmp/catscript.rman Note that this step creates but does not execute the stored script. 4. Every quarter, execute the stored script, passing values for the substitution variables. The following example executes the recovery catalog script named quarterly. The example specifies arc_backup as the name of the media family (set of tapes), bck1206 as part of the FORMAT string and FY06Q4 as the name of the restore point. RUN { EXECUTE SCRIPT quarterly USING arc_backup
Reporting on RMAN Operations bck1206 FY06Q4; }
Page 164 of 212
16.13.6 Printing Stored Scripts

The PRINT SCRIPT command displays a stored script or writes it out to a file. To print stored scripts: 1. Start RMAN and connect to a target database and recovery catalog. 2. Run the PRINT SCRIPT command as follows: PRINT SCRIPT full_backup; To send the contents of a script to a file, use this form of the command: PRINT SCRIPT full_backup TO FILE '/tmp/my_script_file.txt'; For global scripts, the analogous syntax would be as follows: PRINT GLOBAL SCRIPT global_full_backup; PRINT GLOBAL SCRIPT global_full_backup TO FILE '/tmp/my_script_file.txt';
16.13.7 Listing Stored Script Names

Use the LIST ... SCRIPT NAMES command to display the names of scripts defined in the recovery catalog. LIST GLOBAL SCRIPT NAMES and LIST ALL SCRIPT NAMES are the only commands that work when RMAN is connected to a recovery catalog without connecting to a target instance; the other forms of the LIST ... SCRIPT NAMES command require a recovery catalog connection. To list stored script names: 1. Start RMAN and connect to a target database and recovery catalog. 2. Run the LIST ... SCRIPT NAMES command. For example, run the following command to list the names of all global and local scripts that can be executed for the currently connected target database: LIST SCRIPT NAMES; The following example lists only global script names: LIST GLOBAL SCRIPT NAMES; To list the names of all scripts stored in the current recovery catalog, including global scripts and local scripts for all target databases registered in the recovery catalog, use the following form of the command: LIST ALL SCRIPT NAMES; The output will indica\te for each script listed which target database the script is defined for (or whether a script is global).
16.13.8 Deleting Stored Scripts

Use the DELETE GLOBAL SCRIPT command to delete a stored script from the recovery catalog. To delete a stored script: 1. Start RMAN and connect to a target database and recovery catalog. 2. Enter the DELETE SCRIPT command. If you use DELETE SCRIPT without GLOBAL, and there is no stored script for the target database with the specified name, then RMAN looks for a global stored script by the specified name and deletes the global script if it exists. For example, suppose you enter the following command: DELETE SCRIPT 'global_full_backup'; In this case, RMAN looks for a script global_full_backup defined for the connected target database, and if it did not find one, it searches the global scripts for a script called global_full_backup and delete that script. To delete a global stored script, use DELETE GLOBAL SCRIPT: DELETE GLOBAL SCRIPT 'global_full_backup';
Page 165 of 212
16.13.10 Executing a Stored Script at RMAN Startup

To run the RMAN client and start a stored script in the recovery catalog on startup, use the SCRIPT argument when starting the RMAN client. For example, you could enter the following command to execute script /tmp/fbkp.cmd: % rman TARGET / CATALOG rman@catdb SCRIPT '/tmp/fbkp.cmd'; You must connect to a recovery catalog, which contains the stored script, and target database, to which the script will apply, when starting the RMAN client. If local and global stored scripts are defined with the same name, then RMAN always executes the local script.
16.14 Maintaining a Recovery Catalog

This section describes various management and maintenance tasks.
16.14.1 About Recovery Catalog Maintenance

After you have created a recovery catalog and registered your target databases, you need to maintain this catalog. For example, you need to run the RMAN maintenance commands, to update backup records as well as to delete backups that are no longer needed. You must perform this type of maintenance regardless of whether you use RMAN with a recovery catalog. Other types of maintenance, such as upgrading a recovery catalog schema, are specific to use of RMAN with a recovery catalog. If you use a recovery catalog in a Data Guard environment, then special considerations apply for backups and database files recorded in the catalog. backups are accessible to RMAN and how RMAN maintenance commands work with accessible backups.
16.14.2 Resynchronizing the Recovery Catalog

When RMAN performs a resynchronization, it compares the recovery catalog to either the current or backup control file of the target database and updates the catalog with metadata that is missing or changed. Most RMAN commands perform a resynchronization automatically when the target control file is mounted and the catalog is available. In a Data Guard environment, RMAN can perform a reverse resynchronization to update a database control file with metadata from the catalog.
16.14.3 About Resynchronization of the Recovery Catalog

Resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control file stays current. Resynchronizations can be full or partial. In a partial resynchronization, RMAN reads the current control file of the target database to update changed metadata about new backups, new archived redo logs, and so on. RMAN does not resynchronize metadata about the database physical schema. In a full resynchronization, RMAN updates all changed records, including those for the database schema. RMAN performs a full resynchronization after structural changes to database (adding or dropping database files, creating new incarnation, and so on) or after changes to the RMAN persistent configuration. RMAN creates a snapshot control file, which is a temporary backup control file, when it performs a full resynchronization. The database ensures that only one RMAN session accesses a snapshot control file at any point in time. RMAN creates the snapshot control file in an operating system-specific location on the target database host. You can specify the name and location of the snapshot control file. This snapshot control file ensures that RMAN has a consistent view of the control file. Because the control file is intended for short-term use, it is not registered in the catalog. RMAN records the control file checkpoint in the recovery catalog to indicate the currency of the catalog.
16.14.4 Deciding When to Resynchronize the Recovery Catalog

RMAN automatically resynchronizes the recovery catalog when RMAN is connected to a target database and recovery catalog and you have executed RMAN commands. Thus, you should not need to manually run the RESYNC CATALOG command very often. The following sections describe situations requiring a manual catalog resynchronization. Resynchronizing after the Recovery Catalog is Unavailable If the recovery catalog is unavailable when you issue RMAN commands that cause a partial resynchronization, then open the catalog database later and resynchronize it manually with the RESYNC CATALOG command. For example, the target database may be in New York while the
Page 166 of 212
recovery catalog database is in Japan. You may not want to make daily backups of the target database in CATALOG mode, to avoid depending on the availability of a geographically distant database. In such a case you could connect to the catalog as often as feasible and run the RESYNC CATALOG command. Resynchronizing in ARCHIVELOG Mode When You Backup Infrequently Assume that a target database runs in ARCHIVELOG mode. Also assume that you do the following: Back up the database infrequently (for example, hundreds of redo logs are archived between database backups) Generate a high number of log switches every day (for example, 1000 switches between catalog resynchronizations) In this case, you may want to manually resynchronize the recovery catalog regularly because the recovery catalog is not updated automatically when a redo log switch occurs or when a redo log is archived. The database stores metadata about redo log switches and archived redo logs only in the control file. You must periodically resynchronize in order to propagate this information into the recovery catalog. How frequently you need to resynchronize the recovery catalog depends on the rate at which the database archives redo logs. The cost of the operation is proportional to the number of records in the control file that have been inserted or changed since the previous resynchronization. If no records have been inserted or changed, then the cost of resynchronization is very low; if many records have been inserted or changed, then the resynchronization is more time-consuming. Resynchronizing the Recovery Catalog before Control File Records Age out Your goal is to ensure that the metadata in the recovery catalog is current. Because the recovery catalog obtains its metadata from the target control file, the currency of the data in the catalog depends on the currency of the data in the control file. You need to make sure that the backup metadata in the control file is recorded in the catalog before it is overwritten with new records. The CONTROL_FILE_RECORD_KEEP_TIME initialization parameter determines the minimum number of days that records are retained in the control file before they are candidates for being overwritten. Thus, you must ensure that you resynchronize the recovery catalog with the control file record s before these records are erased. You should perform either of the following actions at intervals less than the CONTROL_FILE_RECORD_KEEP_TIME setting: Make a backup, thereby performing an implicit resynchronization of the recovery catalog Manually resynchronize the recovery catalog with the RESYNC CATALOG command Make sure that CONTROL_FILE_RECORD_KEEP_TIME is longer than the interval between backups or resynchronizations. Otherwise, control file records could be reused before they are propagated to the recovery catalog. An extra week is a safe margin in most circumstances. Caution: Never set CONTROL_FILE_RECORD_KEEP_TIME to 0. If you do, then backup records may be overwritten in the control file before RMAN is able to add them to the catalog. One problem can arise if the control file becomes too large. The size of the target database control file grows depending on the number of: Backups that you perform Archived redo logs that the database generates Days that this information is stored in the control file
If the control file grows so large that it can no longer expand because it has reached either the maximum number of blocks or the maximum number of records, then the database may overwrite the oldest records even if their age is less than the CONTROL_FILE_RECORD_KEEP_TIME setting. In this case, the database writes a message to the alert log. If you discover that this situation occurs frequently, then reducing the value of CONTROL_FILE_RECORD_KEEP_TIME and increase the frequency of resynchronizations.
Page 167 of 212
16.14.5 Manually Resynchronizing the Recovery Catalog

Use RESYNC CATALOG to force a full resynchronization of the recovery catalog with a target database control file. Note that you can specify a database unique name with RESYNC FROM DB_UNIQUE_NAME or ALL, depending on whether you want to resynchronize a specific database or all databases in the Data Guard environment. Typically, you would perform this operation when you have the CONFIGURE command for a standby database, but have not yet connected to this standby database. 1. Start RMAN and connect to a target database and recovery catalog. 2. Mount or open the target database if it is not already mounted or open: STARTUP MOUNT; 3. Resynchronize the recovery catalog. Run the RESYNC CATALOG command at the RMAN prompt as follows: RESYNC CATALOG; The following example resynchronizes the control file of standby1: RESYNC CATALOG FROM DB_UNIQUE_NAME standby1; The following variation resynchronizes the control files for all databases in the Data Guard environment that have a DBID of 234325: RESYNC CATALOG FROM DB_UNIQUE_NAME ALL;
16.14.6 Updating the Recovery Catalog after Changing a DB_UNIQUE_ NAME

You may decide to change the DB_UNIQUE_NAME of a database in a Data Guard environment. In this case, you can run the CHANGE DB_UNIQUE_NAME command to associate the metadata stored in recovery catalog for the old DB_UNIQUE_NAME to the new DB_UNIQUE_NAME. Note that the CHANGE DB_UNIQUE_NAME command does not actually change the DB_UNIQUE_NAME of the database itself. Instead, it updates the catalog metadata for the database whose unique name has been or will be changed. The following procedure assumes that the DB_UNIQUE_NAME of the primary database is prodny, and that you have changed the DB_UNIQUE_NAME of a standby database from prodsf1 to prodsf2. You can use the same procedure after changing the DB_UNIQUE_NAME of a primary database, except in step 1 connect RMAN as TARGET to a standby database instead of a primary database. To update the recovery catalog after a DB_UNIQUE_NAME is changed: 1. Connect RMAN to the primary database as TARGET and also to the recovery catalog. For example, enter the following commands: % rman RMAN> CONNECT CATALOG catowner@catdb recovery catalog database Password: password connected to recovery catalog database RMAN> CONNECT TARGET SYS@prodny target database Password: password connected to target database: PRODNY (DBID=39525561) 2. List the DB_UNQUE_NAME values known to the recovery catalog. Run the following LIST command: RMAN> LIST DB_UNIQUE_NAME OF DATABASE; 3. Change the DB_UNIQUE_NAME in the RMAN metadata. The following example changes the database unique name from standby database prodsf1 to prodsf2: RMAN> CHANGE DB_UNIQUE_NAME FROM prodsf1 TO prodsf2;
16.14.7 Unregistering a Target Database from the Recovery Catalog

You can use the UNREGISTER DATABASE command to unregister a database from the recovery catalog. When a database is unregistered from the recovery catalog, all RMAN repository records in the recovery catalog are lost. The database can be registered again, but the recovery catalog records for that database are then based on the
Page 168 of 212
contents of the control file at the time of reregistration. Records older than the CONTROLFILE_RECORD_KEEP_TIME setting in the target database control file are lost. Stored scripts, which are not stored in the control file, are also lost. To unregister a database: 1. Start RMAN and connect as TARGET to the database that you want to unregister. Also connect to the recovery catalog. It is not necessary to connect to the target database, but if you do not, then you must specify the name of the target database in the UNREGISTER command. If more than one database has the same name in the recovery catalog, then you must create a RUN block around the command and use SET DBID to set the DBID for the database. 2. Make a note of the DBID as displayed by RMAN at startup. For example, RMAN outputs a line of the following form when it connects to a target database that is open: connected to target database: PROD (DBID=39525561) If more than one database is registered in the recovery catalog with the same name, then you need the DBID to uniquely identify the database. 3. As a precaution, it may be useful to list all of the backups recorded in the recovery catalog using LIST BACKUP SUMMARY and LIST COPY SUMMARY. This way, you can recatalog backups not known to the control file if you later decide to reregister the database. 4. If your intention is to actually delete all backups of the database completely, then run DELETE statements to delete all existing backups. Do not delete all backups if your intention is only to remove the database from the recovery catalog and rely on the control file to store the RMAN metadata for this database. The following commands illustrate how to delete backups: DELETE BACKUP DEVICE TYPE sbt; DELETE BACKUP DEVICE TYPE DISK; DELETE COPY; RMAN lists the backups that it intends to delete and prompts for confirmation before deleting them. 5. Run the UNREGISTER DATABASE command. For example: UNREGISTER DATABASE; RMAN displays the database name and DBID, and prompts you for a confirmation: database name is "RDBMS" and DBID is 931696259 Do you really want to unregister the database (enter YES or NO)? yes When the process is complete, RMAN outputs the following message: database unregistered from the recovery catalog
16.14.8 Resetting the Database Incarnation in the Recovery Catalog

You create a new incarnation of the database when you open the database with the RESETLOGS option. You can access a record of the new incarnation in the V$DATABASE_INCARNATION view. If you open the database with the RESETLOGS option, and then a new database incarnation record is automatically created in the recovery catalog. The database also implicitly and automatically issues a RESET DATABASE command, which specifies that this new incarnation of the database is the current incarnation. All subsequent backups and log archiving done by the target database is associated with the new database incarnation. Whenever RMAN returns the database to an SCN before the current RESETLOGS SCN, either by means of RESTORE and RECOVER or FLASHBACK DATABASE, the RESET DATABASE TO INCARNATION command is required. However, you do not need to execute RESET DATABASE TO INCARNATION explicitly in the following scenarios because RMAN runs the command implicitly. You use FLASHBACK DATABASE to rewind the database to an SCN in the direct ancestral path. You use FLASHBACK DATABASE to rewind the database to a restore point. The following procedure explains how to reset the database incarnation when recovering through a RESETLOGS. To reset the recovery catalog to an older incarnation for media recovery: 1. Determine the incarnation key of the desired database incarnation. Obtain the incarnation key value by issuing a LIST command: LIST INCARNATION OF DATABASE trgt;
Reporting on RMAN Operations List of Database Incarnations DB Key Inc Key DB Name ------TRGT TRGT DB ID -----1224038686 1224038686 STATUS ------PARENT CURRENT Reset SCN ---------1 59727
Page 169 of 212
Reset Time ---------02-JUL-02 10-JUL-02
------- ------1 1 2 582
The incarnation key is listed in the Inc Key column. 2. Reset the database to the old incarnation. For example, enter: RESET DATABASE TO INCARNATION 2; 3. If the control file of the previous incarnation is available and mounted, then skip to step 6 of this procedure. Otherwise, shut down the database and start it without mounting. For example: SHUTDOWN IMMEDIATE STARTUP NOMOUNT 4. Restore a control file from the old incarnation. If you have a control file tagged, then specify the tag. Otherwise, you can run the SET UNTIL command, as in this example: RUN { SET UNTIL 'SYSDATE-45'; RESTORE CONTROLFILE; # only if current control file is not available } 5. Mount the restored control file: ALTER DATABASE MOUNT; 6. Run RESTORE and RECOVER commands to restore and recover the database files from the prior incarnation, then open the database with the RESETLOGS option. For example, enter: RESTORE DATABASE; RECOVER DATABASE; ALTER DATABASE OPEN RESETLOGS;
16.15 Recovery Catalog Imports

When using IMPORT CATALOG, the source catalog schema is the catalog schema that you want to import into a different schema. The destination catalog schema is the catalog schema into which you intend to import the source catalog schema. By default, RMAN imports metadata from all target databases registered in the source recovery catalog. Optionally, you can specify the list of database IDs to be imported from the source catalog schema. By default, RMAN unregisters the imported databases from the source catalog schema after a successful import. To indicate whether the unregister was successful, RMAN prints messages before and after unregistering the merged databases. You can also specify the NO UNREGISTER option to specify that the databases should not be unregistered from the destination catalog. A stored script is either global or local. It is possible for global scripts, but not local scripts, to have name conflicts during import because the destination schema already contains the script name. In this case, RMAN renames the global script name to COPY OF script_name. For example, RMAN renames bp_cmd to COPY OF bp_cmd. If the renamed global script is still not unique, then RMAN renames it to COPY(2) OF script_name. If this script name also exists, then RMAN renames the script to COPY(3) OF script_name. RMAN continues the COPY(n) OF pattern until the script is uniquely named.
Page 170 of 212
16.15.1 Prerequisites for Importing a Recovery Catalog

As shown in compatibility matrix in Oracle Database Backup and Recovery Reference, a target database, recovery catalog database, and recovery catalog schema can be at different database versions. The recommended practice is to import all existing recovery catalogs into a single recovery catalog at the latest version of the recovery catalog schema. Check the compatibility matrix to determine which schema versions are compatible in your environment. When using IMPORT CATALOG, the version of the source recovery catalog schema must be equal to the current version of the RMAN executable with which you run the command. If the source catalog schema is a lower version, then upgrade it to the current version before importing the schema. If the source recovery catalog schema is a higher version, then retry the import with a higher version RMAN executable. No database can be registered in both the source and destination catalog schema. If a database is currently registered in both catalog schemas, then unregister the database from source catalog schema before performing the import.
16.15.2 Importing a Recovery Catalog

When importing one recovery catalog into another, no connection to a target database is necessary. RMAN only needs connectivity to the source and destination catalogs.In this example, database srcdb contains a 10.2 recovery catalog schema owned by user 102cat, while database destdb contains an 11.1 recovery catalog schema owned by user 111cat. To import a recovery catalog: 1. Start RMAN and connect as CATALOG to the destination recovery catalog schema. For example: % rman RMAN> CONNECT CATALOG 111cat@destdb; 2. Import the source recovery catalog schema, specifying the connection string for the source catalog. For example, enter the following command to import the catalog owned by 102cat on database srcdb: IMPORT CATALOG 102cat@srcdb; A variation is to import metadata for a subset of the target databases registered in the source catalog. You can specify the databases by DBID or database name, as shown in the following examples: IMPORT CATALOG 102cat@srcdb DBID=1423241, 1423242; IMPORT CATALOG 102cat@srcdb DB_NAME=prod3, prod4; 3. Optionally, connect to a target database to check that the metadata was successfully imported. For example, the following commands connect to database prod1 as TARGET and list all backups for this database: LIST BACKUP;
16.16 Moving a Recovery Catalog

The procedure for moving a recovery catalog from one database to another is a variation of the procedure for importing a catalog. In this scenario, the source database is the database containing the existing recovery catalog, while the destination database will contain the moved recovery catalog. To move a recovery catalog from the source database to the destination database: 1. Create a recovery catalog on the destination database, but do not register any databases in the new catalog. 2. Import the source catalog into the catalog created in the preceding step.
16.17 Dropping a Recovery Catalog

The DROP CATALOG command removes those objects that were created as a result of the CREATE CATALOG command. If the user who owns the recovery catalog also owns objects that were not created by CREATE CATALOG, then the DROP CATALOG command does not remove these objects.
Page 171 of 212
If you drop a recovery catalog, and if you have no backups of the recovery catalog schema, then backups of all target databases registered in this catalog may become unusable. However, the control file of every target database will still retain a record of recent backups of this database. The DROP CATALOG command is not appropriate for unregistering a single database from a recovery catalog that has multiple target databases registered. Dropping the recovery catalog deletes the recovery catalog record of backups for all target databases registered in the catalog. To drop a recovery catalog schema: 1. Start RMAN and connect to a target database and recovery catalog. Connect to the recovery catalog as the owner of the catalog schema to be dropped.
The following example connects to a recovery catalog as user catowner: % rman TARGET / CATALOG catowner@catdb 2. Run the DROP CATALOG command: DROP CATALOG; recovery catalog owner is catowner enter DROP CATALOG command again to confirm catalog removal 3. Run the DROP CATALOG command again to confirm: DROP CATALOG; Note: Even after you drop the recovery catalog, the control file still contains records about the backups. To purge RMAN repository records from the control file, re-create the control file.
RMAN Data Reair Concepts
Page 172 of 212
17. RMAN Data Repair Concepts

17.1 Overview of RMAN Data Repair
A principal purpose of a backup and recovery strategy is data protection. The key to a n effective, efficient strategy is to understand the basic options of data repair. Problems Requiring Data Repair While several problems can halt the normal operation of an Oracle database or affect database I/O operations, only the following typically require DBA intervention and data repair: user errors, application errors, and media failures. User Errors User errors occur when, either due to an error in application logic or a manual mistake, data in your database is changed or deleted incorrectly. For example, a user logs in to the wrong database and drops a database table. User errors are estimated to be the greatest single cause of database downtime. Application Errors Sometimes a software malfunction can corrupt data blocks. In a physical corruption, which is also called a media corruption, the database does not recognize the block. Media Failures A media failure occurs when a problem external to the database prevents it from reading from or writing to a file during normal operations. Typical media failures include disk failures and the deletion of database files. Media failures are less common than user or application errors, but your backup and recovery strategy should prepare for them.
17.2 RMAN Data Repair Techniques

Depending on the situations you anticipate, consider incorporating each of the following options into your strategy for responding to data loss, and then set up your database to make these options possible. Data Recovery Advisor This Oracle Database infrastructure can diagnose failures, advise you on how to respond to them, and repair the failures automatically. Logical flashback features This subset of Oracle Flashback Technology features enables you to view or rewind individual database objects or transactions to a past time. These features do not require use of RMAN. Oracle Flashback Database Flashback Database is a block-level recovery mechanism that is similar to media recovery, but is generally faster and does not require a backup to be restored. You can return your whole database to a previous state without restoring old copies of your datafiles from backup, as long as you have enabled flashback logging in advance. You must have a flash recovery area configured for logging for flashback database or guaranteed restore points. Datafile media recovery This form of media recovery enables you to restore datafile backups and apply archived redo logs or incremental backups to recover lost changes. You can either recover a whole database or a subset of the database. Datafile media recovery is the most general-purpose form of recovery and can protect against both physical and logical failures. Block media recovery This form of media recovery enables you to recover individual blocks within a datafile rather than the whole datafile.
Page 173 of 212
Tablespace point-in-time recovery (TSPITR) This is a specialized form of point-in-time recovery in which you recover one or more tablespaces to a time earlier than the rest of the database. In general, the concepts required to use the preceding repair techniques are explained along with the techniques. This chapter explains concepts that are common to several RMAN data repair solutions.
17.3 RMAN Restore Operations

In an RMAN restore operation; you select files to be restored and then run the RESTORE command. Typically, you restore files in preparation for media recovery. You can restore the following types of files: Database (all datafiles) Tablespaces Control files Archived redo logs Server parameter files
You can specify either the default location or a new location for restored datafiles and control files. If you restore to the default location, then RMAN overwrites any files with the same name that currently exist in this location. Alternatively, you can use the SET NEWNAME command to specify new locations for restored datafiles. You can then run a SWITCH command to update the control file to indicate that the restored files in their new locations are now the current datafiles.
17.4 Backup Selection

RMAN uses the records of available backup sets or image copies in the RMAN repository to select the best available backups for use in the restore operation. The most recent backup available or the most recent backup satisfying any UNTIL clause specified in the RESTORE command is the preferred choice. If two backups are from the same point in time, then RMAN prefers image copies over backup sets because RMAN can restore more quickly from image copies than from backup sets (especially those stored on tape). All specifications of the RESTORE command must be satisfied before RMAN restores a backup. Unless limited by the DEVICE TYPE clause, the RESTORE command searches for backups on all device types of configured channels. If no available backup in the repository satisfies all the specified criteria, then RMAN returns an error indicating that the file cannot be restored. If you use only manually allocated channels, then a backup job may fail if there is no usable backup on the media for which you allocated channels. Configuring automatic channels makes it more likely that RMAN can find and restore a backup that satisfies the specified criteria. If backup sets are protected with backup encryption, then RMAN automatically decrypts them when their contents are restored. Transparently encrypted backups require no intervention to restore, as long as the Oracle wallet is open and available. Password-encrypted backups require the correct password to be entered before they can be restored.
17.5 Restore Failover

RMAN automatically uses restore failover to skip corrupted or inaccessible backups and look for usable backups. When a backup is not found, or contains corrupt data, RMAN automatically looks for another backup from which to restore the desired files. RMAN generates messages that indicate the type of failover that it is performing. For example, when RMAN fails over to another backup of the same file, it generates a message similar to the following: failover to piece handle=/u01/backup/db_1 tag=BACKUP_031009 If no usable copies are available, then RMAN searches for previous backups. The message generated is similar to the following example: ORA-19624: operation failed, retry possible
RMAN Data Reair Concepts ORA-19505: failed to identify file "/u01/backup/db_1" ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3 failover to previous backup
Page 174 of 212
RMAN will perform restore failover repeatedly until it has exhausted all possible backups. If all of the backups are unusable or no backups exists, then RMAN attempts to re-create the datafile. Restore failover is also used when there are errors restoring archived redo logs during RECOVER, RECOVER ... BLOCK, and FLASHBACK DATABASE commands.
17.6 Restore Optimization

RMAN uses restore optimization to avoid restoring datafiles from backup when possible. If a datafile is already present in the correct location and its header contains the expected information, then RMAN does not restore the datafile from backup. Note: Restore optimization only checks the datafile header. It does not the scan the datafile body for corrupted blocks. You can use the FORCE option of the RESTORE command to override this behavior and restore the requested files unconditionally. Restore optimization is particularly useful when an operation that restores several datafiles is interrupted. For example, assume that a full database restore encounters a power failure after all except one of the datafiles has been restored. If you run the same RESTORE command again, then RMAN only restores the single datafile that was not restored during the previous attempt. Restore optimization is also used when duplicating a database. If a datafile at the duplicate is in the correct place with the correct header contents, then the datafile is not duplicated. Unlike RESTORE, DUPLICATE does not support a FORCE option. To force RMAN to duplicate a datafile that is skipped due to restore optimization, delete the datafile from the duplicate before running the DUPLICATE command.
17.7 RMAN Media Recovery

In media recovery, RMAN applies changes to restored data to roll forward this data in time. RMAN can perform either datafile media recovery or block media recovery. Datafile media recovery is the application of redo logs or incremental backups to a restored datafile in order to update it to the current time or some other specified time. you can use RMAN to perform complete recovery, database point-in-time recovery (DBPITR), or tablespace point-intime recovery (TSPITR). You can use the RESTORE command to restore backups of lost and damaged datafiles or control files and the RECOVER command to perform media recovery. Block media recovery is the recovery of individual data blocks rather than entire datafiles.
17.8 Selection of Incremental Backups and Archived Redo Logs

RMAN automates media recovery. RMAN automatically restores and applies both incremental backups and archived redo logs in whatever combination is most efficient. If the RMAN repository indicates that no copies of a required log sequence number exist on disk, then will automatically restore the required log from backup. By default, RMAN restores the archived logs to the flash recovery area, if one of the archiving destinations is set to USE_DB_RECOVERY_FILE_DEST. Otherwise, RMAN restores the logs to the first local archiving destination specified in the initialization parameter file.
17.9 Database Incarnations

A database incarnation is created whenever you open the database with the RESETLOGS option. After complete recovery, you can resume normal operations without an OPEN RESETLOGS. After a DBPITR or recovery with a
Page 175 of 212
backup control file, however, you must open the database with the RESETLOGS option, thereby creating a new incarnation of the database. The database requires a new incarnation to avoid confusion when two different redo streams have the same SCNs, but occurred at different times. If you apply the wrong redo to your database, then you will corrupt it. The existence of multiple incarnations of a single database determines how RMAN treats backups that are not in the current incarnation path. In almost all cases, the current database incarnation is the correct one to use. Nevertheless, in some cases resetting the database to a previous incarnation is the best approach. For example, you may be dissatisfied with the results of a point-in-time recovery that you have already performed and want to return the database to a time before the RESETLOGS. An understanding of database incarnations is helpful to prepare for such situations. OPEN RESETLOGS Operations When you open the database with the RESETLOGS option, the database performs the following actions: Archives the current online redo logs (if they are accessible) and then erases the contents of the online redo logs and resets the log sequence number to 1. For example, if the current online redo logs are sequence 1000 and 1001 when you open RESETLOGS, then the database archives logs 1000 and 1001 and then resets the online redo logs to sequence 1 and 2. Creates the online redo log files if they do not currently exist. Initializes redo thread records and online redo log records in the control file to the beginning of the new database incarnation. More specifically, the database sets the redo thread status to closed, sets the current thread sequence in the redo thread records to 1, sets the thread checkpoint of each redo thread to the beginning of log sequence 1, chooses one redo log from each thread and initialize its sequence to 1, and so on. Updates all current datafiles and online redo logs and all subsequent archived redo logs with a new RESETLOGS SCN and time stamp. Because the database will not apply an archived redo log to a datafile unless the RESETLOGS SCN and time stamps match, the RESETLOGS requirement prevents you from corrupting datafiles with archived logs that are not from direct parent incarnations of the current incarnation. The relationship among incarnations is explained more fully in the following section. In previous releases, it was recommended that you back up the database immediately after the OPEN RESETLOGS. Because you can now easily recover a pre-RESETLOGS backup like any other backup, making a new database backup is optional. To perform recovery through RESETLOGS you must have all archived logs generated after the most recent backup and at least one control file (current, backup, or created).
Diagnoising & Repairing Failures
Page 176 of 212
18. Diagnosing and Repairing Failures

18.1 Purpose of Data Recovery Advisor
Data Recovery Advisor is an Oracle Database tool that automatically diagnoses data failures, determines and presents appropriate repair options, and executes repairs at the user's request. In this context, a data failure is a corruption or loss of persistent data on disk. By providing a centralized tool for automated data repair, Data Recovery Advisor improves the manageability and reliability of an Oracle database and thus helps reduce the MTTR. Diagnosing a data failure and devising an optimal strategy for repair requires a high degree of training and experience. Data Recovery Advisor provides the following advantages over traditional repair techniques: Data Recovery Advisor can potentially detect, analyze, and repair data failures before a database process discovers the corruption and signals an error. Early warnings help limit damage caused by corruption. Manually assessing symptoms of data failures and correlating them into a problem statement can be complex, error-prone, and time-consuming. Data Recovery Advisor automatically diagnoses failures, assesses their impact, and reports these findings to the user. Traditionally, users must manually determine repair options along with the repair impact. If multiple failures are present, then users must determine the right sequence of repair execution and try to consolidate repairs. In contrast, Data Recovery Advisor automatically determines the best repair options and runs checks to make sure that these options are feasible in your environment. Execution of a data repair can be complex and error-prone. If you choose an automated repair option, then Data Recovery Advisor executes the repair and verifies its success.
18.2 Basic Concepts of Data Recovery Advisor

This section explains the concepts that you need to familiarize yourself with before using Data Recovery Advisor.
18.2.1 User Interfaces to Data Recovery Advisor

Data Recovery Advisor has both a command-line and GUI interface. The GUI interface is available in Oracle Enterprise Manager Database Control and Grid Control. In the RMAN command-line interface, the Data Recovery Advisor commands are LIST FAILURE, ADVISE FAILURE, REPAIR FAILURE, and CHANGE FAILURE.A failure is detected either automatically by the database or through a manual check such as the VALIDATE command. You can use the LIST FAILURE command to view problem statements for failures and the effect of these failures on database operations. Each failure is uniquely identified by a failure number. In the same RMAN session, you can then use the ADVISE FAILURE command to view repair options, which typically include both automated and manual options. After executing ADVISE FAILURE, you can either repair failures manually or run the REPAIR FAILURE command to repair the failures automatically. A repair is an action that fixes one or more failures. Examples of repairs include block media recovery, datafile media recovery, and Oracle Flashback Database. When you choose an automated repair option, Data Recovery Advisor verifies the repair success and closes the relevant repaired failures.
18.2.2 Data Integrity Checks

A checker is a diagnostic operation or procedure registered with the Health Monitor to assess the health of the database or its components. The health assessment is known as a data integrity check and can be invoked
Page 177 of 212
reactively or proactively. Failures are normally detected reactively. A database operation involving corrupted data results in an error, which automatically invokes a data integrity check that searches the database for failures related to the error. If failures are diagnosed, then they are recorded in the Automatic Diagnostic Repository (ADR), which is a directory structure stored outside of the database. You can use Data Recovery Advisor to generate repair advice and repair failures only after failures have been detected by the database and stored in ADR. You can also invoke a data integrity check proactively. You can execute the check through the Health Monitor, which detects and stores failures in the same way as when the checks are invoked reactively. You can also check for block corruption with the VALIDATE and BACKUP VALIDATE commands.
18.2.3 Failures
A failure is a persistent data corruption that is detected by a data integrity check. A failure can manifest itself as observable symptoms such as error messages and alerts, but a failure is different from a symptom because it represents a diagnosed problem. After a problem is diagnosed by the database as a failure, you can obtain information about the failure and potentially repair it by means of Data Recovery Advisor. Because failure information is not stored in the database itself, the database does not need to be open or mounted for you to access it. You can view failures when the database is started in NOMOUNT mode. Thus, the availability of the control file and recovery catalog does not affect the ability to view detected failures, although it may affect the feasibility of some repairs. Data Recovery Advisor can diagnose failures such as the following: Components such as datafiles and control files that are not accessible because they do not exist, do not have the correct access permissions, have been taken offline, and so on. Physical corruptions such as block checksum failures and invalid block header field values.
Inconsistencies such as a datafile that is older than other database files I/O failures such as hardware errors, operating system driver failures, and exceeding operating system resource limits (for example, the number of open files) Note that Data Recovery Advisor may detect or handle some logical corruptions. But in general, corruptions of this type require help from Oracle Support Services. Failure Status Every failure has a failure status: OPEN or CLOSED. The status of a failure is OPEN until the appropriate repair action is invoked. The status changes to CLOSED after the failure is repaired. Every time you execute LIST FAILURE, Data Recovery Advisor revalidates all open failures and closes failures that no longer exist. Thus, if you fixed some failures as part of a separate procedure, or if the failures were transient problems that disappeared by themselves, running LIST FAILURE will automatically close them. If a failure cannot be revalidated at this time (for example, because of another failure), then LIST FAILURE shows the failure as open. You can use CHANGE FAILURE to change the status of an open failure to CLOSED if you have fixed it manually. However, it makes sense to use CHANGE FAILURE ... CLOSED only if for some reason the failure was not closed automatically. If a failure still exists when you use CHANGE to close it manually, then Data Recover Advisor recreates it with a different failure ID when the appropriate data integrity check is executed. Failure Priority Every failure has a failure priority: CRITICAL, HIGH, or LOW. Data Recovery Advisor only assigns CRITICAL or HIGH priority to diagnosed failures. Failures with CRITICAL priority requires immediate attention because they make the whole database unavailable. For example, a disk containing a current control file may fail. Failures with HIGH priority make a database partly unavailable or unrecoverable and usually have to be repaired quickly. Examples include block corruptions and missing archived redo logs. If a failure was assigned a HIGH priority, but the failure has little impact on database availability and recoverability, then you can downgrade the priority to LOW. A LOW priority indicates that a failure can be ignored until more important failures are fixed. By default LIST FAILURE displays only failures with CRITICAL and HIGH priority. You can use the CHANGE command to change the status for LOW and HIGH failures, but you cannot change the status of CRITICAL failures. The main reason for changing a priority to LOW is to reduce the LIST FAILURE output. Failure grouping for clarity, Data Recovery Advisor groups related failures together. For example, if 20 different blocks in a file are corrupted, then these failures will be grouped under a single parent failure. By default, Data Recovery Advisor lists information about the group of failures, although you can specify the DETAIL option to list
Page 178 of 212
information about the individual subfailures. A subfailure has the same format as a failure. You can get advice on a subfailure and repair it separately or in a combination with any other failure.
18.2.4 Manual Actions and Automatic Repair Options

The ADVISE FAILURE command can present both manual and automatic repair options. Data Recovery Advisor categorizes manual actions as either mandatory or optional. In some cases, the only possible actions are manual. Suppose that no backups exist for a lost control file. In this case, the manual action is to re-create the control file with the CREATE CONTROLFILE statement. Data Recovery Advisor presents this manual action as mandatory because no automatic repair is available. In contrast, suppose that RMAN backups exist for a missing datafile. In this case, the REPAIR FAILURE command can perform the repair automatically by restoring and recovering the datafile. An optional manual action would be to restore the datafile if it was unintentionally renamed or moved. Data Recovery Advisor suggests optional manual actions if they might prevent a more extreme form of repair such as datafile restore and recovery. In contrast to manual actions, automated repairs can be performed by Data Recovery Advisor. The ADVISE FAILURE command presents an option ID for each automated repair option and summarizes the action. Data Recovery Advisor performs feasibility checks before recommending an automated repair. For example, Data Recovery Advisor checks that all backups and archived redo logs needed for media recovery are present and consistent. Data Recovery Advisor may need specific backups and archived redo logs. If the files needed for recovery are not available, then recovery will not possible. Note: For performance reasons, Data Recovery Advisor does not exhaustively check every byte in every file. Thus, it is possible that a feasible repair may still fail because of a corrupted backup or archived redo log. Consolidated Repairs When possible, Data Recovery Advisor consolidates repairs to fix multiple failures into a single repair. A consolidated repair may contain multiple steps. Sometimes a consolidated repair is not possible, as when one failure prevents the creation of repairs for other failures. For example, the feasibility of a data file repair cannot be determined when the control file is missing. In such cases, Data Recovery Advisor generates a repair option for failures that can be repaired and prints a message stating that some selected failures cannot be repaired at this time. After executing the proposed repair, you can repeat the LIST, ADVISE, and REPAIR sequence to repair remaining failures. Repair Scripts Whenever Data Recovery Advisor generates an automated repair option; it creates a script that explains which commands RMAN intends to use to repair the failure. Data Recovery Advisor prints the location of this script, which is a text file residing on the operating system. Example shows a sample repair script, which shows how Data Recovery Advisor plans to repair the loss of datafile 27. Example - Sample Repair Script # restore and recover datafile sql 'alter database datafile 27 offline'; restore datafile 27; recover datafile 27; sql 'alter database datafile 27 online'; If you do not want Data Recovery Advisor to automatically repair the failure, then you can copy the script, edit it, and execute it manually.
18.2.5 Supported Database Configurations

In the current release, Data Recovery Advisor only supports single-instance databases. Oracle Real Application Clusters (Oracle RAC) databases are not supported. If a data failure occurs that brings down all Oracle RAC instances, then you can mount the database in single-instance mode and use Data Recovery Advisor to detect and repair control file, SYSTEM datafile, and data dictionary failures. You can also invoke data recovery checks proactively to test other database components for data failures. This approach will not detect data failures that are local to other cluster instances, for example, an inaccessible datafile.
Page 179 of 212
Data Recovery Advisor cannot use blocks or files transferred from a physical standby database to repair failures on a primary database. Also, you cannot use Data Recovery Advisor to diagnose and repair failures on a standby database. If you are using Enterprise Manager Grid Control in a Data Guard configuration, however, then you can fail over to a standby database and perform repairs on the old primary database.
18.3 Basic Steps of Diagnosing and Repairing Failures

The Data Recovery Advisor workflow begins when you either suspect or discover a failure. You can discover failures in many ways, including error messages, alerts, trace files, and failed data integrity checks. The database can automatically diagnose failures when errors occur. The basic process for responding to failures is to start an RMAN session and perform all of the following steps in the same session: 1. List failures by running the LIST FAILURE command. 2. If you suspect that failures exist that have not been automatically diagnosed by the database, then run VALIDATE DATABASE to check for corrupt blocks and missing files. If VALIDATE detects a problem, then RMAN triggers execution of a failure assessment. If a failure is detected, then RMAN logs it into the Automated Diagnostic Repository, where is can be accessed by Data Recovery Advisor. 3. Determine repair options by running the ADVISE FAILURE command. 4. Choose a repair option. You can repair the failures manually or run the REPAIR FAILURE command to fix them automatically. 5. Return to the first step to confirm that all failures were repaired or determine which failures remain. If appropriate, you can use CHANGE FAILURE command at any time in the Data Recovery Advisor workflow to change the priority of a failure from LOW to HIGH or HIGH to LOW, or close a failure that has been fixed manually.
18.3.1 Listing Failures

If you suspect or know that one or more database failures have occurred, then use LIST FAILURE to obtain information about them. You can list all or a subset of failures and restrict output in various ways. Failures are uniquely identified by failure numbers. Note that these numbers are not consecutive, so gaps between failure numbers have no significance. The LIST FAILURE command does not execute data integrity checks to diagnose new failures; rather, it lists the results of previously executed assessments. Thus, repeatedly executing LIST FAILURE reveals new failures only if the database automatically diagnosed them in response to errors that occurred in between command executions. However, executing LIST FAILURE causes Data Recovery Advisor to revalidate all existing failures. If a user fixed failures manually, or if transient failures disappeared, then Data Recovery Advisor removes these failures from the LIST FAILURE output. If a failure cannot be revalidated at this moment (for example, because of another failure), LIST FAILURE shows the failure as open.
18.3.2 Listing All Failures

The easiest way to determine problems that your database is encountering is to use the LIST FAILURE command. To list all failures: 1. Start RMAN and connect to a target database. The target database instance must be started. 2. Execute the LIST FAILURE command. The following example reports all failures known to Data Recovery Advisor (the output has been reformatted to fit on the page). RMAN> LIST FAILURE; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------142 HIGH OPEN 23-APR-07 One or more non-system datafiles
are missing 101 HIGH OPEN 23-APR-07 Datafile 1:

Diagnoising & Repairing Failures '/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks
Page 180 of 212
In this example, RMAN reports two different failures: a group of missing datafiles and a datafile with corrupt blocks. The output indicates the unique identifier for each failure (12 and 5), the priority, status, and detection time. 3. Optionally, execute LIST FAILURE ... DETAIL to list failures individually. Data Recovery Advisor consolidates failures when possible. Specify the DETAIL option to list failures individually. For example, if multiple block corruptions exist in a file, then specifying the DETAIL option would list each of the block corruptions. The following example lists detailed information about failure 101. RMAN> LIST FAILURE 101 DETAIL; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------101 HIGH OPEN 23-APR-07 Datafile 1:
'/disk1/oradata/prod/system01.dbf' contains one or more corrupt blocks List of child failures for parent failure ID 101 Failure ID Priority Status Time Detected Summary
---------- -------- --------- ------------- ------104 HIGH OPEN 23-APR-07 Block 56416 in datafile 1:
'/disk1/oradata/prod/system01.dbf' is media corrupt Impact: Object BLKTEST owned by SYS might be unavailable 4. Proceed to determine how to repair the failures displayed by the LIST FAILURE command.
18.3.3 Listing a Subset of Failures

Besides providing more verbose output, LIST FAILURE also enables you to restrict output. For example, you can execute LIST FAILURE with the CRITICAL, HIGH, LOW, or CLOSED options to list only failures with a particular status or priority. You can also exclude specified failures from the output by specifying EXCLUDE FAILURE. To list a subset of failures: 1. Start RMAN and connect to a target database. The target database instance must be started. 2. Execute LIST FAILURE with the desired options. The following examples illustrate some LIST FAILURE commands: LIST FAILURE LOW; LIST FAILURE CLOSED; LIST FAILURE EXCLUDE FAILURE 234234;
18.4 Checking for Block Corruptions by Validating the Database

The database invokes data integrity checks reactively when a user transaction is trying to access corrupted data. In some cases, latent failures can go undetected. For example, when a data block corruption error occurs, the database reactively executes a data integrity check that validates the block on which the error occurred and other blocks in its immediate vicinity. However, blocks outside of the vicinity may be corrupted. Also, corrupted blocks that are never read by the database will never be detected by a reactive data integrity check. One effective way to execute a data integrity check proactively is to run the VALIDATE or BACKUP VALIDATE commands in RMAN. These commands can check datafiles and control files for physical and logical corruption. If RMAN discovers block corruptions, then it logs them into the Automatic Diagnostic Repository and creates one or more failures. You can then use Data Recovery Advisor to list information about the failures and repair them. To validate the database: 1. Start RMAN and connect to a target database. The target database must be mounted. 2. Validate the desired database files.
Page 181 of 212
The following example uses VALIDATE DATABASE to check for physical and logical corruption in the whole database (partial sample output included). Because it indicates that some datafiles are missing, the
SKIP INACCESSIBLE clause is specified.

RMAN> VALIDATE CHECK LOGICAL SKIP INACCESSIBLE DATABASE;
Starting validate at 23-APR-07 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=103 device type=DISK could not access datafile 28 skipping inaccessible file 28 RMAN-06060: WARNING: skipping datafile compromises tablespace USERS recoverability RMAN-06060: WARNING: skipping datafile compromises tablespace USERS recoverability channel ORA_DISK_1: starting validation of datafile
channel ORA_DISK_1: specifying datafile(s) for validation input datafile file number=00001 name=/disk1/oradata/prod/system01.dbf input datafile file number=00002 name=/disk1/oradata/prod/sysaux01.dbf input datafile file number=00022 name=/disk1/oradata/prod/undotbs01.dbf input datafile file number=00023 name=/disk1/oradata/prod/cwmlite01.dbf input datafile file number=00024 name=/disk1/oradata/prod/drsys01.dbf input datafile file number=00025 name=/disk1/oradata/prod/example01.dbf input datafile file number=00026 name=/disk1/oradata/prod/indx01.dbf input datafile file number=00027 name=/disk1/oradata/prod/tools01.dbf channel ORA_DISK_1: validation complete, elapsed time: 00:00:25 List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------1 FAILED 0 3536 57600 637711
File Name: /disk1/oradata/prod/system01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------Data Index Other . . . File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------27 OK 0 1272 1280 400914 1 0 0 41876 7721 4467
File Name: /disk1/oradata/prod/tools01.dbf Block Type Blocks Failing Blocks Processed ---------- -------------- ---------------Data 0 0
Diagnoising & Repairing Failures Index Other 0 0 0 8
Page 182 of 212
validate found one or more corrupt blocks See trace file /disk1/oracle/log/diag/rdbms/prod/prod/trace/prod_ora_2596.trc for details channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: specifying datafile(s) for validation including current control file for validation including current SPFILE in backup set channel ORA_DISK_1: validation complete, elapsed time: 00:00:01 List of Control File and SPFILE =============================== File Type Status Blocks Failing Blocks Examined
------------ ------ -------------- --------------SPFILE OK 0 0 2 512
Control File OK
Finished validate at 23-APR-07
18.5 Determining Repair Options

Use the ADVISE FAILURE command to display repair options after running LIST FAILURE in an RMAN session. This command prints a summary of the failures and implicitly closes all open failures that are already repaired. Where appropriate, the ADVISE FAILURE command presents a list of manual and automated repair options. Manual options, which are categorized as either mandatory or optional, appear first. In some cases, an optional manual fix can avoid more extreme actions such as restoring and recovering datafiles. As a rule, use the repair technique that has the least effect on the database and the least possibility for error. Determining Repair Options for All Failures If one or more failures exist, then you should typically use LIST FAILURE to show information about the failures and then use ADVISE FAILURE in the same RMAN session to obtain a report of your repair options. To determine repair options for all failures: 1. List failures. 2. In the same RMAN session, execute ADVISE FAILURE. The following example requests repair options for all failures known to Data Recovery Advisor and include sample output (reformatted to fit the page). RMAN> ADVISE FAILURE; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary
analyzing automatic repair options; this may take some time

Diagnoising & Repairing Failures using channel ORA_DISK_1 analyzing automatic repair options complete Mandatory Manual Actions ======================== no manual actions available
Page 183 of 212
Optional Manual Actions ======================= 1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it Automated Repair Options ======================== Option Repair Description ------ -----------------1 Restore and recover datafile 28; Perform block media recovery of block 56416 in file 1 Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_660500184.hm In the preceding example, ADVISE FAILURE reports two failures: a missing datafile and a datafile with corrupt blocks. The command does not list mandatory manual actions, but it suggests making sure that the missing datafile was not accidentally renamed or removed. The automated repair option involves block media recovery and restoring and recovering the missing datafile. ADVISE FAILURE lists the location of the repair script. The following variation of the same example shows the output when the RMAN backups or archived redo logs needed for the automated repair are not available. Note that ADVISE FAILURE now shows mandatory manual actions. RMAN> ADVISE FAILURE; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary
analyzing automatic repair options; this may take some time allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=103 device type=DISK analyzing automatic repair options complete
Mandatory Manual Actions ======================== 1. If file /disk1/oradata/prod/users01.dbf was unintentionally renamed or moved, restore it
Page 184 of 212
2. Contact Oracle Support Services if the preceding recommendations cannot be used, or if they do not fix the failures selected for repair
Optional Manual Actions ======================= no manual actions available
Automated Repair Options ======================== Option Repair Description ------ -----------------1 Perform block media recovery of block 56416 in file 1 Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_1863891774.hm 3. Proceed to determine how to repair the failures shown in the LIST FAILURE output. Determining Repair Options for a Subset of Failures You can also request repair options for specific failures. You can specify failures by status (CRITICAL, HIGH, or LOW) or by failure number. You can also use EXCLUDE FAILURE to exclude one or more failures from the report. To determine repair options for a subset of failures: 1. List failures. 2. In the same RMAN session, execute ADVISE FAILURE with the desired options. The following example requests repair options for failure 101 only. RMAN> ADVISE FAILURE 101; List of Database Failures ========================= Failure ID Priority Status Time Detected Summary
analyzing automatic repair options; this may take some time using channel ORA_DISK_1 analyzing automatic repair options complete
Mandatory Manual Actions ======================== no manual actions available
Optional Manual Actions ======================= no manual actions available
Automated Repair Options ======================== Option Repair Description

Diagnoising & Repairing Failures ------ -----------------1 Perform block media recovery of block 56416 in file 1 Strategy: The repair includes complete media recovery with no data loss
Page 185 of 212
Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_708819503.hm 3. Proceed to determine how to repair the failures displayed by the LIST FAILURE command.
18.6. Repairing Failures

This section explains how to use Data Recovery Advisor to repair failures automatically.
18.6.1. About Repairing Failures

If ADVISE FAILURE suggests manual repairs, then try these first. If manual repairs are not possible, or if they do not repair all failures, then you can use REPAIR FAILURE to automatically fix failures suggested in the most recent ADVISE FAILURE command in your current RMAN session. By default, REPAIR FAILURE prompts for confirmation before it begins executing. You can suppress the confirmation prompt by specifying the NOPROMPT option. After it starts executing, the command indicates the current phase of repair. Depending on the circumstances, RMAN may prompt for a response. After executing a repair, RMAN reevaluates all existing failures on the chance that they may have been fixed during this repair. Before performing a repair, it is typically advisable to preview it by specifying the PREVIEW option. RMAN does not make any repairs and generates a script with all repair actions and comments. If you do not specify a particular repair option, then RMAN uses the first repair option of the most recent ADVISE FAILURE command in the current session. By default the repair script is displayed to standard output. You can use the SPOOL command to write the script to an editable file.
18.6.2. Repairing a Failure

By default the script is displayed to standard output. You can use the SPOOL command to write the script to an editable file. To repair a failure: 1. List failures. 2. Display repair options. 3. Optionally, execute REPAIR FAILURE PREVIEW. The following example previews the first repair options displayed by the previous ADVISE FAILURE command in the RMAN session. RMAN> REPAIR FAILURE PREVIEW;
Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm contents of repair script: # restore and recover datafile sql 'alter database datafile 28 offline'; restore datafile 28; recover datafile 28; sql 'alter database datafile 28 online'; # block media recovery recover datafile 1 block 56416; 4. Execute REPAIR FAILURE. The following repair restores and recovers one datafile and performs block media recovery on one corrupt block. RMAN prompts for confirmation that it should perform the repair. The user-entered text is in bold.
Diagnoising & Repairing Failures RMAN> REPAIR FAILURE;
Page 186 of 212
Strategy: The repair includes complete media recovery with no data loss Repair script: /disk1/oracle/log/diag/rdbms/prod/prod/hm/reco_475549922.hm contents of repair script: # restore and recover datafile sql 'alter database datafile 28 offline'; restore datafile 28; recover datafile 28; sql 'alter database datafile 28 online'; # block media recovery recover datafile 1 block 56416;
Do you really want to execute the above repair (enter YES or NO)? YES executing repair script sql statement: alter database datafile 28 offline Starting restore at 23-APR-07 using channel ORA_DISK_1 channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00028 to /disk1/oradata/prod/users01.dbf channel ORA_DISK_1: reading from backup piece /disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp channel ORA_DISK_1: piece handle=/disk2/PROD/backupset/2007_04_18/o1_mf_nnndf_TAG20070418T182042_32fjzd3z_.bkp tag=TAG20070418T182042
channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:03 Finished restore at 23-APR-07 Starting recover at 23-APR-07 using channel ORA_DISK_1 starting media recovery media recovery complete, elapsed time: 00:00:01 Finished recover at 23-APR-07
sql statement: alter database datafile 28 online Starting recover at 23-APR-07
using channel ORA_DISK_1 searching flashback logs for block images until SCN 429690 finished flashback log search, restored 1 blocks
starting media recovery

Diagnoising & Repairing Failures media recovery complete, elapsed time: 00:00:03
Page 187 of 212
Finished recover at 23-APR-07 repair failure complete 5. Optionally, execute LIST FAILURE to confirm
18.6.3 Changing Failure Status and Priority

In some situations, you may want to use the CHANGE FAILURE command to alter the status or priority of a failure. For example, if a block corruption has HIGH priority, you may want to change it to LOW temporarily if the block is in a little-used tablespace. If you repair a failure by a means other than the REPAIR FAILURE command, then Data Recovery Advisor closes it implicitly the next time you execute LIST FAILURE. For this reason, you do not normally need to execute the CHANGE FAILURE ... CLOSED command. You should need to use this command only if the automatic failure revalidation fails, but you believe the failure no longer exists. Note that if you use CHANGE FAILURE to close a failure that still exists, then Data Recovery Advisor re-creates it with a different failure ID when the appropriate data integrity check is executed. Typically, you specify the failures that you want to change by failure number. You can also change failures in bulk by specifying ALL, CRITICAL, HIGH, or LOW. You can change a failure to CLOSED or to PRIORITY HIGH or PRIORITY LOW. To change the status or priority of a failure: 1. List failures. The following example lists one failure involving corrupt data blocks. RMAN> LIST FAILURE;
List of Database Failures =========================
Failure ID Priority Status
Time Detected Summary
'/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks 2. Execute CHANGE FAILURE with the desired options. The following example changes the priority of a block corruption failure from HIGH to LOW. RMAN> CHANGE FAILURE 101 PRIORITY LOW;
'/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks
Do you really want to change the above failures (enter YES or NO)? YES changed 1 failures to LOW priority 3. Optionally, execute LIST FAILURE ALL to view the change.
Page 188 of 212
Note that if you execute LIST FAILURE without ALL, then the command lists failures with LOW priority only if no CRITICAL or HIGH priority failures exist. RMAN> LIST FAILURE ALL;
---------- -------- --------- ------------- ------142 HIGH OPEN 23-APR-07 One or more non-system datafiles are missing 101 LOW OPEN 23-APR-07 Datafile 25:
'/disk1/oradata/prod/example01.dbf' contains one or more corrupt blocks
Validating Database Files and Backups
Page 189 of 212
19. Validating Database Files and Backups

19.1 Purpose of RMAN Validation
The main purpose of RMAN validation is to check for corrupt blocks and missing files. You can also use RMAN to determine whether backups can be restored. You can use the following RMAN commands to perform validation: VALIDATE BACKUP ... VALIDATE RESTORE ... VALIDATE
19.2 Basic Concepts of RMAN Validation

The database prevents operations that result in unusable backup files or corrupted restored datafiles. The database automatically does the following: Blocks access to datafiles while they are being restored or recovered Permits only one restore operation for each datafile at a time Ensures that incremental backups are applied in the correct order Stores information in backup files to allow detection of corruption Checks a block every time it is read or written in an attempt to report a corruption as soon as it has been detected A corrupt block is a block that has been changed so that it differs from what Oracle Database expects to find. Block corruptions can be caused by a number of different failures including, but not limited to the following: Faulty disks and disk controllers Faulty memory Oracle Database software defects
In a physical corruption, which is also called a media corruption, the database does not recognize the block at all: the checksum is invalid, the block contains all zeros, or the header and footer of the block do not match. In a logical corruption, the contents of the block are logically inconsistent. Examples of logical corruption include corruption of a row piece or index entry. Block corruptions can also be divided into interblock corruption and intrablock corruption. In intrablock corruption, the corruption occurs within the block itself and can be either physical or logical corruption. In an interblock corruption, the corruption occurs between blocks and can only be logical corruption. Oracle Database supports different techniques for detecting, repairing, and monitoring block corruption. The technique depends on the corruption type. For example, the V$DATABASE_BLOCK_ CORRUPTION view tracks intrablock corruptions, while the Automatic Diagnostic Repository (ADR) tracks all types of corruptions.
19.3 Checking for Block Corruption with the VALIDATE Command

You can use the VALIDATE command to manually check for physical and logical corruptions in database files. This command performs the same types of checks as BACKUP VALIDATE, but VALIDATE can check a larger selection of objects. For example, you can validate individual blocks with the VALIDATE DATAFILE ... BLOCK command. When validating whole files, RMAN checks every block of the input files. If the backup validation discovers corrupt blocks, then RMAN updates the V$DATABASE_BLOCK_CORRUPTION view with rows describing the corruptions.
Page 190 of 212
Use VALIDATE BACKUPSET when you suspect that one or more backup pieces in a backup set are missing or have been damaged. This command checks every block in a backup set to ensure that the backup can be restored. If RMAN finds block corruption, then it issues an error and terminates the validation. Note that VALIDATE BACKUPSET enables you to choose which backups to check, whereas the VALIDATE option of the RESTORE command lets RMAN choose. To use VALIDATE to check database files and backups: 1. Start RMAN and connect to a target database. 2. Execute the VALIDATE command with the desired options. For example, to validate all datafiles and control files (and the server parameter file if one is in use), execute the following command at the RMAN prompt: RMAN> VALIDATE DATABASE; Alternatively, you can validate a particular backup set by using the form of the command shown in the following example (sample output included). RMAN> VALIDATE BACKUPSET 22;
Starting validate at 17-AUG-06 using channel ORA_DISK_1 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=89 device type=SBT_TAPE channel ORA_SBT_TAPE_1: Oracle Secure Backup channel ORA_DISK_1: starting validation of datafile backup set channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/RDBMS/backupset/2007_08_16/o1_mf_nnndf_TAG20070816T153 034_2g774bt2_.bkp channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/RDBMS/backupset/2007_08_16/o1_mf_nnndf_TAG20070 816T153034_2g774bt2_.bkp tag=TAG20070816T153034 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: validation complete, elapsed time: 00:00:01 Finished validate at 17-AUG-06 The following example illustrates how you can check individual data blocks within a datafile for corruption. RMAN> VALIDATE DATAFILE 1 BLOCK 10; Starting validate at 17-AUG-06 using channel ORA_DISK_1 channel ORA_DISK_1: starting validation of datafile channel ORA_DISK_1: specifying datafile(s) for validation input datafile file number=00001 name=/disk1/oracle/dbs/tbs_01.f channel ORA_DISK_1: validation complete, elapsed time: 00:00:01
List of Datafiles ================= File Status Marked Corrupt Empty Blocks Blocks Examined High SCN ---- ------ -------------- ------------ --------------- ---------1 OK 0 2 127 481907
File Name: /disk1/oracle/dbs/tbs_01.f Block Type Blocks Failing Blocks Processed

Page 191 of 212
---------- -------------- ---------------Data Index Other 0 0 0 36 31 58
Finished validate at 17-AUG-06
19.4 Parallelizing the Validation of a Datafile

If you need to validate a large datafile, then RMAN can parallelize the work by dividing the file into sections and processing each file section in parallel. If multiple channels are configured or allocated, and if you want the channels to parallelize the validation, then specify the SECTION SIZE parameter of the VALIDATE command. If you specify a section size that is larger than the size of the file, then RMAN does not create a multisection backup of the file. If you specify a small section size that would produce more than 256 sections, then RMAN increases the section size to a value that results in exactly 256 sections. To parallelize the validation of a datafile: 1. Start RMAN and connect to a target database. The target database must be mounted or open. 2. Run VALIDATE with the SECTION SIZE parameter. The following example allocates two channels and validates a large datafile. The section size is 1200 MB. RUN { ALLOCATE CHANNEL c1 DEVICE TYPE DISK; ALLOCATE CHANNEL c2 DEVICE TYPE DISK; VALIDATE DATAFILE 1 SECTION SIZE 1200M; } Validating Database Files with BACKUP VALIDATE You can use the BACKUP VALIDATE command to do the following: Check data files for physical and logical block corruption Confirm that all database files exist and are in the correct locations When you run BACKUP VALIDATE, RMAN reads the files to be backed up in their entirety, as it would during a real backup. RMAN does not, however, actually produce any backup sets or image copies. You cannot use the BACKUPSET, MAXCORRUPT, or PROXY parameters with BACKUP VALIDATE. To validate specific backup sets, run the VALIDATE command. To validate files with the BACKUP VALIDATE command: 1. Start RMAN and connect to a target database and recovery catalog (if used). 2. Run the BACKUP VALIDATE command. For example, you can validate that all database files and archived logs can be backed up by running a command as shown in the following example. This command checks for physical corruptions only. BACKUP VALIDATE DATABASE ARCHIVELOG ALL; To check for logical corruptions in addition to physical corruptions, run the following variation of the preceding command: BACKUP VALIDATE CHECK LOGICAL DATABASE ARCHIVELOG ALL; In the preceding examples, the RMAN client displays the same output that it would if it were really backing up the files. If RMAN cannot back up one or more of the files, then it issues an error message. For example, RMAN may show output similar to the following: RMAN-00571: ===========================================================
Page 192 of 212
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 08/29/2007 14:33:47 ORA-19625: error identifying file /oracle/oradata/trgt/arch/archive1_6.dbf ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional information: 3
19.5 Validating Backups before Restoring Them

You can run RESTORE ... VALIDATES tests whether RMAN can restore a specific file or set of files from a backup. RMAN chooses which backups to use. The database must be mounted or open for this command. You do not have to take datafiles offline when validating the restore of datafiles, because validation of backups of the datafiles only reads the backups and does not affect the production datafiles. When validating files on disk or tape, RMAN reads all blocks in the backup piece or image copy. RMAN also validates offsite backups. The validation is identical to a real restore operation except that RMAN does not write output files. Note: As an additional test measure, you can perform a trial recovery with the RECOVER ... TEST command. A trial recovery applies redo in a way similar to normal recovery, but it is in memory only and it rolls back its changes after the trial. To validate backups with the RESTORE command: 1. Run the RESTORE command the VALIDATE option. This following example illustrates validating the restore of the database and all archived redo logs: RESTORE DATABASE VALIDATE; RESTORE ARCHIVELOG ALL VALIDATE; If you do not see an RMAN error stack, then skip the subsequent steps. The lack of error messages means that RMAN had confirmed that it can use these backups successfully during a real restore a nd recovery. 2. If you see error messages in the output and the RMAN-06026 message, then investigate the cause of the problem. If possible, correct the problem that is preventing RMAN from validating the backups and retry the validation. The following error means that RMAN cannot restore one or more of the specified files from your available backups: RMAN-06026: some targets not found - aborting restore The following sample output shows that RMAN encountered a problem reading the specified backup: RMAN-03009: failure of restore command on c1 channel at 12-DEC-06 23:22:30 ORA-19505: failed to identify file "oracle/dbs/1fafv9gl_1_1" ORA-27037: unable to obtain file status SVR4 Error: 2: No such file or directory Additional i
Performing Complete Database Recovery
Page 193 of 212
20. Performing Complete Database Recovery

20.1 Purpose of Complete Database Recovery
This chapter assumes that some or all of your datafiles are lost or damaged. Typically, this situation is caused by a media failure or accidental deletion. Your goal is to return the database to normal operation by restoring the damaged files from RMAN backups and recovering all database changes.
20.2 Preparing for Complete Database Recovery

While RMAN simplifies most database restore and recovery tasks, you must still plan your database restore and recovery strategy based on which database files have been lost and your recovery goal.
20.3 Identifying the Database Files to Restore or Recover

The techniques for determining which files require restore or recovery depend upon the type of file that is lost.
20.3.1 Identifying a Lost Control File

It is usually obvious when the control file of your database is lost. The database shuts down immediately when any of the multiplexed control files becomes inaccessible. Also, the database reports an error if you try to start it without a valid control file at each location specified in the CONTROL_FILES initialization parameter. Loss of some but not all copies of your control file does not require you to restore a control file from backup. If at least one control file remains intact, then you can either copy an intact copy of the control file over the damaged or missing control file, or update the initialization parameter file so that it does not refer to the damaged or missing control file. After the CONTROL_FILES parameter references only present, intact copies of the control file, you can restart your database. If you restore the control file from backup, then you must perform media recovery of the whole database and then open it with the OPEN RESETLOGS option, even if no datafiles need to be restored.
20.3.2 Identifying Datafiles Requiring Media Recovery

When and how to recover depends on the state of the database and the location of its datafiles. Identifying Datafiles with RMAN an easy technique for determining which datafiles are missing is to run a VALIDATE DATABASE command, which attempts to read all specified datafiles. For example, start the RMAN client and run the following commands to validate the database (sample output included). Example - BACKUP VALIDATE DATABASE RMAN> VALIDATE DATABASE; Starting validate at 20-OCT-06 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=90 device type=DISK could not read file header for datafile 7 error reason 4 RMAN-00571: =========================================================== RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS =============== RMAN-00571: =========================================================== RMAN-03002: failure of backup command at 10/20/2007 13:05:43 RMAN-06056: could not access datafile 7 The output in Example indicates that datafile 7 is inaccessible. You can then run the REPORT SCHEMA command to obtain the tablespace name and filename for datafile 7 as follows (sample output included): RMAN> REPORT SCHEMA;
Page 194 of 212
Report of database schema for database with db_unique_name RDBMS Preparing for Complete Database Recovery
List of Permanent Datafiles =========================== File Size(MB) Tablespace RB segs Datafile Name
---- -------- -------------------- ------- -----------------------1 2 3 4 5 6 7 450 86 15 2 2 2 2 SYSTEM SYSAUX UD1 SYSTEM TBS_1 TBS_1 TBS_2 *** *** *** *** *** *** *** +DATAFILE/tbs_01.f +DATAFILE/tbs_ax1.f +DATAFILE/tbs_undo1.f +DATAFILE/tbs_02.f +DATAFILE/tbs_11.f +DATAFILE/tbs_12.f +DATAFILE/tbs_21.f
List of Temporary Files ======================= File Size(MB) Tablespace Maxsize(MB) Tempfile Name
---- -------- -------------------- ----------- -------------------1 40 TEMP 32767 +DATAFILE/tbs_tmp1.f
Identifying Datafiles with SQL Although VALIDATE DATABASE is a good technique for determining whether files are inaccessible, you may want to use SQL queries to obtain more detailed information. To determine whether datafiles require media recovery: 1. Start SQL*Plus and connect to the target database instance with administrator privileges. 2. Determine the status of the database by executing the following SQL query: SELECT STATUS FROM V$INSTANCE; If the status is OPEN, then the database is open. Nevertheless, some datafiles may require media recovery. 3. Query V$DATAFILE_HEADER to determine the status of your datafiles. Run the following SQL statements to check the datafile headers: COL FILE# FORMAT 999 COL STATUS FORMAT A7 COL ERROR FORMAT A10 COL TABLESPACE_NAME FORMAT A10 COL NAME FORMAT A30
SELECT FILE#, STATUS, ERROR, RECOVER, TABLESPACE_NAME, NAME FROM OR V$DATAFILE_HEADER WHERE RECOVER = 'YES' (RECOVER IS NULL AND ERROR IS NOT NULL);
Each row returned represents a datafile that either requires media recovery or has an error requiring a restore. Check the RECOVER and ERROR columns. RECOVER indicates whether a file needs media recovery, and ERROR indicates whether there was an error reading and validating the datafile header. If ERROR is not NULL, then the datafile header cannot be read and validated. Check for a temporary hardware or operating system problem causing the error. If there is no such problem, you must restore the file or switch to a copy. If the ERROR column is NULL and the RECOVER column is YES, then the file requires media recovery (and may also require a restore from backup).
Page 195 of 212
Note: Because V$DATAFILE_HEADER only reads the header block of each datafile, it does not detect all problems that require the datafile to be restored. For example, this view cannot tell whether a datafile contains corrupt data blocks. 4. Optionally, query V$RECOVER_FILE to list datafiles requiring recovery by datafile number with their status and error information. For example, execute the following query: SELECT FILE#, ERROR, ONLINE_STATUS, CHANGE#, TIME FROM V$RECOVER_FILE;
Note: You cannot use V$RECOVER_FILE with a control file restored from backup or a control file that was recreated after the time of the media failure affecting the datafiles. A restored or re-created control file does not contain the information needed to update V$RECOVER_FILE accurately. To find datafile and tablespace names, you can also perform useful joins using the datafile number and the V$DATAFILE and V$TABLESPACE views. For example: COL DF# FORMAT 999 COL DF_NAME FORMAT A35 COL TBSP_NAME FORMAT A7 COL STATUS FORMAT A7 COL ERROR FORMAT A10 COL CHANGE# FORMAT 99999999
SELECT r.FILE# AS df#, d.NAME AS df_name, t.NAME AS tbsp_name, d.STATUS, r.ERROR, r.CHANGE#, r.TIME FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t WHERE t.TS# = d.TS# AND d.FILE# = r.FILE#; The ERROR column identifies the problem for each file requiring recovery.
20.3.3 Determining the DBID of the Database

In situations requiring the recovery of your server parameter file or control file from autobackup, you need to know the DBID. You should record the DBID along with other basic information about your database. If you do not have a record of the DBID of your database, then you can find it in the following places without opening your database: The DBID is used in forming the filename for the control file autobackup. If you have any text files that preserve the output from an RMAN session, then the DBID is displayed by the RMAN client when it starts up and connects to your database. Typical output follows: % rman TARGET /
Recovery Manager: Release 11.1.0.6.0 - Production on Wed Jul 11 17:51:30 2007 Copyright (c) 1982, 2007, Oracle. All rights reserved.
connected to target database: PROD (DBID=36508508)
20.3.4 Previewing Backups Used in Restore Operations

You can apply RESTORE ... PREVIEW to any RESTORE operation to create a detailed list of every backup to be used in the requested RESTORE operation, as well as the necessary target SCN for recovery after the RESTORE operation is complete. This command accesses the RMAN repository to query the backup metadata, but does not actually read the backup files to ensure that they can be restored. As an alternative to RESTORE ... PREVIEW, you can use the RESTORE... VALIDATE HEADER command. In addition to listing the files needed for restore and recovery, the RESTORE ... VALIDATE HEADER command validates the backup file headers to determine whether
Page 196 of 212
the files on disk or in the media management catalog correspond to the metadata in the RMAN repository. When planning your restore and recovery operation, use RESTORE ... PREVIEW or RESTORE ... VALIDATE HEADER to ensure that all required backups are available or to identify situations in which you may want to direct RMAN to use or avoid specific backups. To preview backups to be used in a restore operation: 1. Run a RESTORE command with the PREVIEW option. For example, run one of the following commands: RESTORE DATABASE PREVIEW; RESTORE ARCHIVELOG FROM TIME 'SYSDATE-7' PREVIEW; If the report produced by RESTORE ... PREVIEW provides too much information, then specify the SUMMARY option as shown in the following example: RESTORE DATABASE PREVIEW SUMMARY; If satisfied with the output, then stop here. If the output indicates that RMAN will request a backup from a tape that you know is temporarily unavailable, then continue with this procedure. 2. If needed, use the CHANGE command to set the backup status of any temporarily unavailable backups to UNAVAILABLE. 3. Optionally, run RESTORE ... PREVIEW again to confirm that the restore will not attempt to use unavailable backups.
20.3.5 Recalling Offsite Backups

Some media managers provide status information to RMAN about which backups are offsite. An offsite backup is stored in a remote location, such as a secure storage facility, and cannot be restored unless the media manager retrieves the media. Offsite backups are marked as AVAILABLE in the RMAN repository even though the media must be retrieved from storage before the backup can be restored. If RMAN attempts to restore a offsite backup, then the restore job fails. You can use RESTORE ... PREVIEW to identify offsite backups. The command output indicates whether backups are stored offsite, as shown by the text at the end of the sample output in Example Example RESTORE ... PREVIEW Output List of Backup Sets =================== BS Key Size Device Type Elapsed Time Completion Time
------- ---------- ----------- ------------ --------------9 2.25M BP Key: 9 SBT_TAPE 00:00:00 21-MAY-07 Tag: TAG20070521T144258
Status: AVAILABLE
Compressed: NO
Handle: 0aii9k7i_1_1
Media: 0aii9k7i_1_1
---- ------- ---------- --------- ---------- --------1 1 1 1 1 1 1 2 3 4 5 6 392314 392541 392545 392548 395066 395095 21-MAY-07 392541 21-MAY-07 392545 21-MAY-07 392548 21-MAY-07 395066 21-MAY-07 395095 21-MAY-07 395355 21-MAY-07 21-MAY-07 21-MAY-07 21-MAY-07 21-MAY-07 21-MAY-07
List of remote backup files ============================ Handle: aii9k7i_1_1 Media: 0aii9k7i_1_1
validation succeeded for backup piece

Page 197 of 212
Finished restore at 21-MAY-07 released channel: dev1 You can use RESTORE ... PREVIEW RECALL to instruct the media manager to make offsite backups available. To recall offsite backups: If backups are stored offsite, then execute a RESTORE ... PREVIEW command with the RECALL option. The following example initiates recall for the offsite archived log backups shown in Example (sample output included): RESTORE ARCHIVELOG ALL PREVIEW RECALL; The following sample output indicates that RMAN initiated a recall: Preparing for Complete Database Recovery List of Backup Sets ===================
BS Key
Size
------- ---------- ----------- ------------ --------------9 2.25M BP Key: 9 SBT_TAPE 00:00:00 21-MAY-07 Tag: TAG20070521T144258
Status: AVAILABLE
Compressed: NO
Handle: VAULT0aii9k7i_1_1
Media: /tmp,VAULT0aii9k7i_1_1
---- ------- ---------- --------- ---------- --------1 1 1 1 1 1 1 2 3 4 5 6 392314 392541 392545 392548 395066 395095 21-MAY-07 392541 21-MAY-07 392545 21-MAY-07 392548 21-MAY-07 395066 21-MAY-07 395095 21-MAY-07 395355 21-MAY-07 21-MAY-07 21-MAY-07 21-MAY-07 21-MAY-07 21-MAY-07
Initiated recall for the following list of remote backup files ========================================================== Handle: VAULT0aii9k7i_1_1 Media: /tmp,VAULT0aii9k7i_1_1
validation succeeded for backup piece Finished restore at 21-MAY-07 released channel: dev1 2. Run the RESTORE ... PREVIEW command. If necessary, return to the previous step until no backups needed for the restore are reported as offsite.
20.4 Validating Backups before Restoring Them

You can run RMAN commands to test the availability of usable backups for any RESTORE operation, or test the contents of a specific backup for use in RESTORE operations. The contents of the backups are actually read and checked for corruption. You have the following validation options:
Page 198 of 212
RESTORE ... VALIDATE tests whether RMAN can restore a specific object from a backup. RMAN chooses which backups to use. VALIDATE BACKUPSET tests the validity of a backup set that you specify.
20.4.1 Restoring Archived Redo Logs Needed for Recovery

RMAN restore archived redo log files from backup automatically as needed to perform recovery. You can also restore archived redo logs manually to save the time needed to restore these files later during the RECOVER command, or if you want to store the restored archived redo log files in some new location. By default, RMAN restores archived redo logs with names constructed using the LOG_ARCHIVE_FORMAT and the LOG_ARCHIVE_DEST_1 parameters of the target database. These parameters are combined in a platform-specific fashion to form the name of the restored archived log. Restoring Archived Redo Logs to a New Location You can override the default location for restored archived redo logs with the SET ARCHIVELOG DESTINATION command. This command manually stages archived logs to different locations while a database restore is occurring. During recovery, RMAN knows where to find the newly restored archived logs; it does not require them to be in the location specified in the initialization parameter file. To restore archived redo logs to a new location: 1. Start RMAN and connect to a target database. 2. Ensure that the database is mounted or open. 3. Perform the following operations within a RUN command: a. Specify the new location for the restored archived redo logs using SET ARCHIVELOG DESTINATION. b. Either explicitly restore the archived redo logs or execute commands that automatically restore the logs. The following sample RUN command explicitly restores all backup archived logs to a new location: RUN { SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore'; RESTORE ARCHIVELOG ALL; # restore and recover datafiles as needed . . . } The following example sets the archived log destination and then uses RECOVER DATABASE to restore archived logs from this destination automatically: RUN { SET ARCHIVELOG DESTINATION TO '/oracle/temp_restore'; RESTORE DATABASE; RECOVER DATABASE; # restores and recovers logs automatically }
20.5 Performing Complete Database Recovery

20.5.1. About Complete Database Recovery
You use the RESTORE and RECOVER commands to restore and recover the database. During the recovery, RMAN automatically restores backups of any needed archived redo logs. If backups are stored on a media manager, then channels must be configured in advance or a RUN block with ALLOCATE CHANNEL commands must be used to enable access to backups stored there. If RMAN restores archived redo logs to the flash recovery area during a recovery, then it automatically deletes the restored logs after they applying them to the datafiles.
Page 199 of 212
Otherwise, you can use the DELETE ARCHIVELOG command to delete restored archived redo logs from disk when they are no longer needed for recovery. For example, you can enter the following command: RECOVER DATABASE DELETE ARCHIVELOG;
20.5.2. Performing Complete Recovery of the Whole Database

This scenario assumes that database trgt has lost most or all of its datafiles. It also assumes that the database uses a flash recovery area. Note that after restore and recovery of a whole database, when the database is opened, any missing temporary tablespaces recorded in the control file are re-created with their previous creation size, AUTOEXTEND, and MAXSIZE attributes. Only temporary tablespaces that are missing are re-created. If a tempfile exists at the location recorded in the RMAN repository but has an invalid header, then RMAN does not re-create the tempfile. If the tempfiles were originally created as Oracle-managed files, then they are re-created in the current DB_CREATE_FILE_DEST location. Otherwise, they are re-created at their previous locations. If RMAN is unable to re-create the file due to an I/O error or some other cause, then the error is reported in the alert log and the database open operation continues. To restore and recover the whole database: 1. Start RMAN and connect to a target database. For example, enter the following command: % rman RMAN> CONNECT TARGET / RMAN displays the database status when it connects: not started, not mounted, not open (when the database is mounted but not open), or none (when the database is open). 2. If the database is not mounted, then mount but do not open the database. For example, enter the following command: STARTUP MOUNT; 3. Use the SHOW command to see which channels are preconfigured. For example, enter the following command (sample output is included): SHOW ALL;
RMAN configuration parameters for database with db_unique_name PROD1 are: . . . CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS "SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so"; If the necessary devices and channels are already configured, then no action is necessary. Otherwise, you can use the CONFIGURE command to configure automatic channels, or include ALLOCATE CHANNEL commands within a RUN block. 4. If restoring password-protected encrypted backups, then specify the password. Use the SET DECRYPTION IDENTIFIED BY command to specify a password for password-protected backups, as shown in the following example (where password represents the actual password that you enter): SET DECRYPTION IDENTIFIED BY password;
Page 200 of 212
If you created backups with different passwords, then you can run the SET DECRYPTION IDENTIFIED BY password command multiple times, specifying all of the possible passwords that might be required to restore the backups. 5. Restore and recover the database. Do one of the following: If you are restoring all datafiles to their original locations, then execute RESTORE DATABASE and RECOVER DATABASE sequentially at the RMAN prompt. For example, enter the following commands if automatic channels are configured (sample output included): RMAN> RESTORE DATABASE;
Starting restore at 20-JUN-06 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=35 device type=DISK allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00001 to /disk1/oracle/dbs/tbs_01.f channel ORA_DISK_1: restoring datafile 00002 to /disk1/oracle/dbs/tbs_ax1.f . . . Finished restore at 20-JUN-06 RMAN> RECOVER DATABASE;
Starting recover at 20-JUN-06 using channel ORA_DISK_1 allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=34 device type=SBT_TAPE channel ORA_SBT_TAPE_1: Oracle Secure Backup
starting media recovery
channel ORA_DISK_1: starting archived log restore to default destination channel ORA_DISK_1: restoring archived log archived log thread=1 sequence=5 channel ORA_DISK_1: restoring archived log archived log thread=1 sequence=6 . . . channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20070620T
Page 201 of 212
113128_29jhr197_.bkp channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20 070620T113128_29jhr197_.bkp tag=TAG20070620T113128 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_5_29jhv47k _.arc thread=1 sequence=5 channel default: deleting archived log(s) . . . media recovery complete, elapsed time: 00:00:15 Finished recover at 20-JUN-06 If you manually allocate channels, then you must issue the RESTORE and RECOVER commands together within a RUN block as shown in the following example: RUN { ALLOCATE CHANNEL c1 DEVICE TYPE sbt; RESTORE DATABASE; RECOVER DATABASE; } If you are restoring some datafiles to new locations, then execute RESTORE DATABASE and RECOVER DATABASE sequentially in a RUN command. Use the SET NEWNAME to rename datafiles. The following example restores the database, specifying new names for three of the datafiles, and then recovers the database: RUN { SET NEWNAME FOR DATAFILE 2 TO '/disk2/df2.dbf'; SET NEWNAME FOR DATAFILE 3 TO '/disk2/df3.dbf'; SET NEWNAME FOR DATAFILE 4 TO '/disk2/df4.dbf'; RESTORE DATABASE; SWITCH DATAFILE ALL; RECOVER DATABASE; } 6. Examine the output to see if media recovery was successful. If so, open the database. For example, enter the following command: ALTER DATABASE OPEN;
20.5.3 Performing Complete Recovery of a Tablespace

In the basic scenario, the database is open, and some but not all of the datafiles are damaged. You want to restore and recover the damaged tablespace while leaving the database open so that the rest of the database remains available. This scenario assumes that database trgt has lost tablespace users. To restore and recover a tablespace: 1. Start RMAN and connect to a target database. 2. If the database is open, then take the datafile requiring recovery offline.
Page 202 of 212
For example, enter the following command to take users offline: SQL "ALTER TABLESPACE users OFFLINE IMMEDIATE"; 3. Use the SHOW command to see which channels are preconfigured. For example, enter the following command (sample output is included): SHOW ALL;
RMAN configuration parameters for database with db_unique_name PROD1 are: . . . CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default CONFIGURE DEVICE TYPE DISK PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE DEVICE TYPE SBT_TAPE PARALLELISM 1 BACKUP TYPE TO BACKUPSET; # default CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' PARMS "SBT_LIBRARY=/usr/local/oracle/backup/lib/libobk.so"; If the necessary devices and channels are already configured, then no action is necessary. Otherwise, you can use the CONFIGURE command to configure automatic channels, or include ALLOCATE CHANNEL commands within a RUN block. 4. If restoring password-protected encrypted backups, then specify the password. Use the SET DECRYPTION IDENTIFIED BY command to specify a password for password-protected backups, as shown in the following example (where password represents the actual password that you enter): SET DECRYPTION IDENTIFIED BY password; 5. Restore and recover the tablespace. Do one of the following: If you are restoring datafiles to their original locations, then run the RESTORE TABLESPACE and RECOVER TABLESPACE commands at the RMAN prompt. For example, enter the following command if automatic channels are configured (sample output included): RMAN> RESTORE TABLESPACE users;
Starting restore at 20-JUN-06 allocated channel: ORA_DISK_1 channel ORA_DISK_1: SID=37 device type=DISK allocated channel: ORA_SBT_TAPE_1 channel ORA_SBT_TAPE_1: SID=38 device type=SBT_TAPE channel ORA_SBT_TAPE_1: Oracle Secure Backup
channel ORA_DISK_1: starting datafile backup set restore channel ORA_DISK_1: specifying datafile(s) to restore from backup set channel ORA_DISK_1: restoring datafile 00012 to /disk1/oracle/dbs/users01.f channel ORA_DISK_1: restoring datafile 00013 to /disk1/oracle/dbs/users02.f channel ORA_DISK_1: restoring datafile 00021 to /disk1/oracle/dbs/users03.f channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_nnndf_TAG20070620T 105435_29jflwor_.bkp channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_nnndf_TAG20 070620T105435_29jflwor_.bkp tag=TAG20070620T105435
Page 203 of 212
channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:01 Finished restore at 20-JUN-06
RMAN> RECOVER TABLESPACE users;
Starting recover at 20-JUN-06 using channel ORA_DISK_1 using channel ORA_SBT_TAPE_1
starting media recovery archived log for thread 1 with sequence 27 is already on disk as file /disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_27_29jjmtc9_.ar c archived log for thread 1 with sequence 28 is already on disk as file /disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_28_29jjnc5x_.ar c . . . channel ORA_DISK_1: starting archived log restore to default destination channel ORA_DISK_1: restoring archived log archived log thread=1 sequence=5 channel ORA_DISK_1: restoring archived log archived log thread=1 sequence=6 channel ORA_DISK_1: restoring archived log archived log thread=1 sequence=7 . . . channel ORA_DISK_1: reading from backup piece /disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20070620T 113128_29jhr197_.bkp channel ORA_DISK_1: piece handle=/disk1/oracle/work/orcva/TKRM/backupset/2007_06_20/o1_mf_annnn_TAG20 070620T113128_29jhr197_.bkp tag=TAG20070620T113128 channel ORA_DISK_1: restored backup piece 1 channel ORA_DISK_1: restore complete, elapsed time: 00:00:02 archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_5_29jkdvjq _.arc thread=1 sequence=5 channel default: deleting archived log(s) archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_5_29jkdvjq
Page 204 of 212
_.arc RECID=91 STAMP=593611179 archived log file name=/disk1/oracle/work/orcva/TKRM/archivelog/2007_06_20/o1_mf_1_6_29jkdvbz _.arc thread=1 sequence=6 channel default: deleting archived log(s) . . . media recovery complete, elapsed time: 00:00:01 Finished recover at 20-JUN-06 If you are restoring some datafiles to new locations, then execute RESTORE TABLESPACE and RECOVER TABLESPACE in a RUN command. Use the SET NEWNAME to rename datafiles. The following example restores the datafiles in tablespaces users to a new location, and then performs recovery. Assume that the old datafiles were stored in the /disk1 path and the new ones will be stored in the /disk2 path. RUN { # specify the new location for each datafile SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users01.f' TO '/disk2/users01.f'; SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users02.f' TO '/disk2/users02.f'; SET NEWNAME FOR DATAFILE '/disk1/oracle/dbs/users03.f' TO '/disk2/users03.f'; RESTORE TABLESPACE users; SWITCH DATAFILE ALL; # update control file with new filenames
RECOVER TABLESPACE users; } 6. Examine the output to see if recovery was successful. If so, bring the recovered tablespace back online. For example, enter the following command: SQL "ALTER TABLESPACE users ONLINE";
20.5.4 Performing Complete Recovery of a Datafile after Switching to a Copy

If you have image copies of the inaccessible datafiles in the flash recovery area, then you can use the SWITCH DATAFILE ... TO COPY command to point the control file at the datafile copy and then use RECOVER to recover lost changes. When the original location can be used again, you can switch datafile back to the original location. Because you do not need to restore backups, this recovery technique takes less time than traditional restore and recovery. Note: A SWITCH TABLESPACE ... TO COPY command is also supported for cases when all datafiles in a tablespace are lost and copies of all datafiles exist. In the basic scenario, the database is open, and some but not all of the datafiles are damaged. During the course of the day, a datafile goes missing due to storage failure. You need to repair this file, but cannot afford the time to do a restore and recovery from a backup. You decide to use a recent image copy backup as the new file, thus eliminating restore time. This scenario assumes that database trgt has lost datafile 4. To switch to a datafile copy and perform recovery: 1. Start RMAN and connect to a target database.
Page 205 of 212
2. If the database is open, then take the tablespace requiring recovery offline. For example, enter the following command to take datafile 4 offline: SQL "ALTER DATABASE DATAFILE 4 OFFLINE"; 3. Switch the offline datafile to the latest copy. For example, enter the following command to point the control file to the latest image copy of datafile 4: SWITCH DATAFILE 4 TO COPY; 4. Recover the datafile with the RECOVER DATAFILE command. For example, enter the following command (sample output included): RECOVER DATAFILE 4; RMAN automatically restores a rchived redo logs and incremental backups. Because the database uses a flash recovery area, RMAN automatically deletes them after they have been applied. 5. Examine the output to see if recovery was successful. If so, bring the recovered datafile back online. For example, enter the following command to bring datafile 4 online: SQL "ALTER DATABASE DATAFILE 4 ONLINE";
Performing Block Media Recovery
Page 206 of 212
21. Performing Block Media Recovery

21.1 Purpose of Block Media Recovery
You can us e block media recovery to recover one or more corrupt data blocks within a datafile. Block media recovery provides the following advantages over datafile media recovery: Lowers the Mean Time to Recover (MTTR) because only blocks needing recovery are restored and recovered Enables affected datafiles to remain online during recovery without block media recovery, if even a single block is corrupt, then you must take the datafile offline and restore a backup of the datafile. You must apply all redo generated for the datafile after the backup was created. The entire file is unavailable until media recovery completes. With block media recovery, only the blocks actually being recovered are unavailable during the recovery. Block media recovery is most useful for physical corruption problems that involve a small, well-known number of blocks. Block-level data loss usually results from intermittent, random I/O errors that do not cause widespread data loss, as well as memory corruptions that get written to disk. Block media recovery is not intended for cases where the extent of data loss or corruption is unknown and the entire datafile requires recovery. In such cases, datafile media recovery is the best solution.
21.2 Basic Concepts of Block Media Recovery

In most cases, the database marks a block as media corrupt and then writes it to disk when the corruption is first encountered. No subsequent read of the block will be successful until the block is recovered. You can only perform block recovery on blocks that are marked corrupt or fail a corruption check. You perform block media recovery with the RECOVER ... BLOCK command. By default, RMAN searches the flashback logs for good copies of the blocks, and then searches for the blocks in full or level 0 incremental backups. When RMAN finds good copies, it restores them and performs media recovery on the blocks. Block media recovery can only use redo logs for media recovery, not level 1 incremental backup.
21.2.1 Identification of Corrupt Blocks

The V$DATABASE_BLOCK_CORRUPTION view displays blocks marked corrupt by database components such as RMAN commands, ANALYZE, dbv, SQL queries, and so on. The following types of corruption result in rows added to this view: Physical corruption (sometimes called media corruption) The database does not recognize the block: the checksum is invalid, the block contains all zeros, or the block header is fractured. Physical corruption checking is enabled by default. You can turn off checksum checking by specifying the NOCHECKSUM option of the BACKUP command, but other physical consistency checks, such as checks of the block headers and footers, cannot be disabled. Logical corruption The block has a valid checksum, the header and footer match, and so on, but the contents a re logically inconsistent. Block media recovery cannot repair logical block corruption. Logical corruption checking is disabled by default. You can turn it on by specifying the CHECK LOGICAL option of the BACKUP, RESTORE, RECOVER, and VALIDATE commands. The database can detect some corruptions by validating relationships between blocks and segments, but cannot detect them by a check of an individual block. The V$DATABASE_BLOCK_CORRUPTION view does not record this type of corruption.
Page 207 of 212
21.2.2 Missing Redo during Block Recovery

Like datafile media recovery, block media recovery cannot generally survive a missing or inaccessible archived log, although it will attempt restore failover when looking for usable copies of archived redo log files. Also, block media recovery cannot survive physical redo corruptions that result in checksum failure. However, block media recovery can survive gaps in the redo stream if the missing or corrupt redo records do not affect the blocks being recovered. Whereas datafile recovery requires an unbroken series of redo changes from the beginning of recovery to the end, block media recovery only requires an unbroken set of redo changes for the blocks being recovered.
Note: Each block is recovered independently during block media recovery, so recovery may be successful for a subset of blocks.
When RMAN first detects missing or corrupt redo record s during block media recovery, it does not immediately signal an error because the block undergoing recovery may become a newed block later in the redo stream. When a block is newed all previous redo for that block becomes irrelevant because the redo applies to an old incarnation of the block. For example, the database can new a block when users drop or truncate a table and then use the block for other data.
21.2.3 Prerequisites for Block Media Recovery

The following prerequisites apply to the RECOVER ... BLOCK command: The target database must run in ARCHIVELOG mode and be open or mounted with a current control file. The target database must not be a standby database. The backups of the datafiles containing the corrupt blocks must be full or level 0 backups and not proxy copies. If only proxy copy backups exist, then you can restore them to a non-default location on disk, in which case RMAN considers them datafile copies and searches them for blocks during block media recovery. RMAN can use only archived redo logs for the recovery. RMAN cannot use level 1 incremental backups. Block media recovery cannot survive a missing or inaccessible archived redo log, although it can sometimes survive missing redo records.
21.2.4 Recovering Individual Blocks

Typically, block corruption is reported in the following locations: Results of the LIST FAILURE, VALIDATE, or BACKUP ... VALIDATE command The V$DATABASE_BLOCK_CORRUPTION view Error messages in standard output The alert log User trace files Results of the SQL commands ANALYZE TABLE and ANALYZE INDEX Results of the DBVERIFY utility Third-party media management output
For example, you may discover the following messages in a user trace file: ORA-01578: ORACLE data block corrupted (file # 7, block # 3) ORA-01110: data file 7: '/oracle/oradata/trgt/tools01.dbf' ORA-01578: ORACLE data block corrupted (file # 2, block # 235) ORA-01110: data file 2: '/oracle/oradata/trgt/undotbs01.dbf' In the following procedure, you identify the blocks that require recovery and then use any available backup to perform the restore and recovery of these blocks.To recover specific data blocks:
Page 208 of 212
1. Obtain the datafile numbers and block numbers of the corrupted blocks. The easiest way to locate trace files and the alert log is to connect SQL*Plus to the target database and execute the following query: SELECT NAME, VALUE FROM V$DIAG_INFO; 2. Start RMAN and connect to the target database, which must be mounted or open. 3. Run the SHOW ALL command to make sure that the appropriate channels are preconfigured. 4. Run the RECOVER ... BLOCK command at the RMAN prompt, specifying the file and block numbers for the corrupted blocks. The following example recovers two blocks. RECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 19; You can also specify various options to control RMAN behavior. The following example indicates that only backups with tag mondayam will be used when searching for blocks. You could use the FROM BACKUPSET option to restrict the type of backup that RMAN searches, or EXCLUDE FLASHBACK LOG to restrict RMAN from searching the flashback logs. RECOVER DATAFILE 8 BLOCK 13 DATAFILE 2 BLOCK 199 FROM TAG mondayam;
21.2.5 Recovering All Blocks in V$DATABASE_BLOCK_CORRUPTION

In this scenario, RMAN automatically recovers all blocks listed in the V$DATABASE_BLOCK_ CORRUPTION view. To recover all blocks logged in V$DATABASE_BLOCK_CORRUPTION: 1. Start SQL*Plus and connect to the target database. 2. Query V$DATABASE_BLOCK_CORRUPTION to determine whether corrupt blocks exist. For example, execute the following statement: SQL> SELECT * FROM V$DATABASE_BLOCK_CORRUPTION; 3. Start RMAN and connect to the target database. 4. Recover all blocks marked corrupt in V$DATABASE_BLOCK_CORRUPTION. The following command repairs all physically corrupted blocks recorded in the view: RMAN> RECOVER CORRUPTION LIST; After the blocks are recovered, the database removes them from V$DATABASE_BLOCK_ CORRUPTION.
Performing RMAN Tablespace Point-in-Tim e Recovery
Page 209 of 212
22. Performing RMAN Tablespace Point-in-Time Recovery (TSPITR)

22.1 Purpose of RMAN TSPTIR
Recovery Manager (RMAN) automatic TSPITR enables you to quickly recover one or more tablespaces in a database to an earlier time without affecting the rest of the tablespaces and objects in the database. RMAN TSPITR is most useful for the following situations: You want to recover a logical database to a point different from the rest of the physical database, when multiple logical databases exist in separate tablespaces of one physical database. For example, you maintain logical databases in the orders and personnel tablespaces. An incorrect batch job or DML statement corrupts the data in only one of the tablespaces. You want to recover data lost after DDL operations that change the structure of tables. You cannot use Flashback Table to rewind a table to before the point of a structural change such as a truncate table operation. You want to recover a table after it has been dropped with the PURGE option. You want to recover from the logical corruption of a table. You can also use Flashback Database to rewind data, but you must rewind the entire database rather than just a subset. Also, unlike TSPITR, the Flashback Database feature necessitates the overhead of maintaining flashback logs. The point in time to which you can flash back the database is more limited than the TSPITR window, which extends back to your earliest recoverable backup.
22.2 Basic Concepts of RMAN TSPITR

You perform TSPITR by using the RMAN RECOVER TABLESPACE command. The target instance contains the tablespace to be recovered to the target time. The target time is the point in time or SCN of the tablespace after TSPITR completes. The auxiliary instance is a database instance used in the recovery process to perform the work of recovery. The auxiliary instance has other files associated with it, such a s a control file, parameter file, and online logs, but they are not part of the auxiliary set. The recovery set includes the datafiles that are in the tablespaces that you intend to recover. The auxiliary set includes the datafiles required for TSPITR of the recovery set that are not they part of the recovery set. The auxiliary set typically includes: The SYSTEM and SYSAUX tablespaces Datafiles containing rollback or undo segments from the target database instance Temporary tablespaces
The auxiliary destination is an optional location on disk which can be used to store any of the auxiliary set datafiles, control files and online redo logs of the auxiliary instance during TSPITR. Files stored here can be deleted after TSPITR is complete. 1. Queries SYS.TS_PITR_CHECK for the tablespaces in the recovery set. If the query returns rows, then RMAN does not proceed with the TSPITR. 2. Creates the auxiliary instance, starts it, and connects to it (if there is no existing auxiliary instance). 3. Takes the tablespaces to be recovered offline in the target database. 4. Restores a backup control file from a point in time before the target time to the auxiliary instance. 5. Restores the datafiles from the recovery set and the auxiliary set to the auxiliary instance.
Page 210 of 212
Files are restored either in locations you specify for each file, or the original location of the file (for recovery set files) or in the auxiliary destination (for auxiliary set files, if you used the AUXILIARY DESTINATION argument of RECOVER TABLESPACE). 6. Recovers the restored datafiles in the auxiliary instance to the specified time. 7. Opens the auxiliary database with the RESETLOGS option. 8. Exports the dictionary metadata about objects in the recovered tablespaces to the target database. 9. Shuts down the auxiliary instance. 10. Issues SWITCH commands on the target database instance if new names were given to the datafiles in the recovery set. The target database control file now points to the datafiles in the recovery set that were just recovered at the auxiliary instance. 11. Imports the dictionary metadata from the auxiliary instance to the target instance, allowing the recovered objects to be accessed. 12. Deletes all auxiliary set files. At this point the TSPITR is complete. The recovery set datafiles are returned to their contents a t the specified point in time, and belong to the target database.
22.2.1 Basic Steps of RMAN TSPITR

When you are ready to perform the actual TSPITR, the basic steps depend on which technique you use. The following sections describe your options: Performing Fully Automated RMAN TSPITR You specify an auxiliary destination and allow RMAN to manage all aspects of the TSPITR. This is the simplest technique and is recommended unless you specifically need more control over the operation. Performing Customized RMAN TSPITR with an RMAN-Managed Auxiliary Instance You base your TSPITR on the behavior of fully automated TSPITR, possibly still using an auxiliary destination, but customize one or more aspects of the behavior. For example, you could specify the location of auxiliary set or recovery set files, or specify initialization parameters or channel configurations for the auxiliary instance created and managed by RMAN. Performing RMAN TSPITR Using Your Own Auxiliary Instance In this technique, you take responsibility for setting up, starting, stopping and cleaning up the auxiliary instance used in TSPITR, and possibly also manage the TSPITR process using some of the methods available in customized TSPITR with an automatic auxiliary instance. Prerequisites and Consequences of TSPITR A number of database problems cannot be resolved with TSPITR. The following list explains TSPITR prerequisites in terms of when you cannot perform TSPITR: You cannot perform TSPITR if you do not have archived redo logs or if the database runs in NOARCHIVELOG mode. You cannot recover dropped tablespaces. You cannot recover a renamed tablespace to a point in time before it was renamed. If you try to perform a TSPITR to an SCN earlier than the rename operation, then RMAN cannot find the new tablespace name in the repository as of that earlier SCN (because the tablespace did not have that name at that SCN). In this situation, you must recover the entire database to a point in time before the tablespace was renamed. The tablespace will be found under the name it had at that earlier time. If the constraints for the tables in tablespace tbs1 are contained in tablespace tbs2, then you cannot recover tbs1 without recovering tbs2 as well. You cannot use TSPITR to recover any of the following objects: Replicated master tables Partial tables (for example, if you perform RMAN TSPITR on partitioned tables and spread partitions across multiple tablespaces, then you must recover all tablespaces which include
Page 211 of 212
partitions of the table.) Tables with VARRAY columns, nested tables, or external files Snapshot logs and snapshot tables Tablespaces containing undo or rollback segments Tablespaces that contain objects owned by SYS, including rollback segments Consequences of TSPITR After TSPITR completes, RMAN recovers the datafiles in the recovery set to the target time. Note the following consequences of TSPITR: If a datafile was added after the point to which RMAN is recovering, then an empty datafile by the same name will be included in the tablespace after RMAN TSPITR. TSPITR will not recover query optimizer statistics for recovered objects. You must gather new statistics after the TSPITR completes. If you run TSPITR on a tablespace and bring the tablespace online at time t, then backups of the tablespace created before time t are no longer usable for recovery with a current control file. You cannot run TSPITR again on this tablespace to recover it to any time less than or equal to time t, nor can you use the current control file to recover the database to any time less than or equal to t. Therefore, you must back up the recovered tablespace as soon as TSPITR is complete.
22.2.2 Special Considerations When Not Using a Recovery Catalog

If you do not use a recovery catalog when performing TSPITR, then note the following special considerations: The undo segments at the time of the TSPITR must be part of the auxiliary set. Because RMAN has no historical record of the undo in the control file, RMAN assumes that the current rollback or undo segments were the same segments present at the time to which recovery is performed. If the undo segments have changed since that time, then TSPITR will fail. TSPITR to a time that is too old may not succeed if Oracle has reused the control file records for needed backups. (In planning your database, set the CONTROL_FILE_RECORD_KEEP_TIME initialization parameter to a value large enough to ensure that control file records needed for TSPITR are kept.) Assume that you run TSPITR on a tablespace, and then bring the tablespace online at time t. When not using a recovery catalog, the current control file has no record of the older incarnation of the recovered tablespace. Thus, recovery with a current control file that involves this tablespace cannot use a backup taken prior to time t. You can, however, perform incomplete recovery of the whole database to any time less than or equal to t, if you can restore a backup control file from before time t.
22.3 Planning and Preparing for TSPITR

You must carry out the following steps when preparing for TSPITR: Choosing the Right Target Time for TSPITR Determining the Recovery Set Identifying and Preserving Objects That Will Be Lost After TSPITR
22.3.1 Choosing the Right Target Time for TSPITR

It is extremely important that you choose the right target time or SCN for your TSPITR. After you bring a tablespace online after TSPITR, you cannot use any backup from a time earlier than the moment you brought the tablespace online. In practice, you cannot make a second attempt at TSPITR if you choose the wrong target time the first time, unless you are using a recovery catalog.
Page 212 of 212
If you have a recovery catalog, then you can perform repeated TSPITR operations to different target times because the catalog contains tablespace history information. If RMAN uses only a control file, however, then it does not have the tablespace history. In this case, RMAN knows only the current set of tablespaces. The tablespace on which TSPITR was performed has a creation time of the time it was brought online. Assume a situation in which you are not using a recovery catalog. You run TSPITR on a tablespace and then bring the tablespace online at 5 p.m. on Friday. Backups of the tablespace created before 5 p.m. Friday are no longer usable for recovery with a current control file. You cannot run TSPITR again on this tablespace with a target time earlier than 5 p.m. Friday, nor can you use the current control file to recover the database to any time earlier than 5 p.m. Friday. Your only option is point-in-time recovery of the entire database using a restored control file. To investigate past states of your data to identify the target time for TSPITR, you can use Oracle Flashback Query, Oracle Transaction Query and Oracle Flashback Version Query to find the point in time when unwanted database changes occurred.
22.3.2 Determining the Recovery Set

Initially, your recovery set includes the datafiles for the tablespaces you intend to recover. However, if objects in the tablespaces you need have relationships (such as constraints) to objects in other tablespaces, then you will have to account for this relationship before you can perform TSPITR. You have the following choices when faced with such a relationship: Add the tablespace including the related objects to your recovery set Remove the relationship
INDEX
Page I of VIII
INDEX 1. Introduction to Oracle Net Services..................................................................................................................1 1.1 About Oracle Net Services .............................................................................................................................1 1.2 Connectivity...................................................................................................................................................1 1.2.1 Client/Server Application Connections ......................................................................................................1 1.2.2. Web Client Application Connections ........................................................................................................1 1.3 Prerequisites to Establishing Connectivity.......................................................................................................3 1.4 Alternate Connection using Oracle Net Configuration Assistant .......................................................................4 1.5 Connectivity Concepts ...................................................................................................................................5 1.5.1 Database Service and Database Instance Identification ............................................................................5 1.6 Enhanced Service Accessibility with Multiple Listeners....................................................................................7 1.7 Listener Architecture ......................................................................................................................................9 2. Configuring Naming Methods......................................................................................................................... 11 2.1 Naming Method Configuration Overview ....................................................................................................... 11 2.2 About Connect Descriptors........................................................................................................................... 11 2.3 Naming Methods.......................................................................................................................................... 12 2.3.1 Using the Easy Connect Naming Method................................................................................................ 12 2.3.2 Using Easy Connect Naming on the Client ............................................................................................. 14 2.4 Configuring the Local Naming Method .......................................................................................................... 14 3. Oracle Net Listener Administration ................................................................................................................ 16 3.1 Oracle Net Listener Configuration Overview.................................................................................................. 16 3.1.1 Oracle Net Listener Configuration during Installation............................................................................... 16 3.1.2 Customizing Oracle Net Listener Configuration....................................................................................... 17 3.1.3 Configuring Passwords for Oracle Net Listener....................................................................................... 17 3.1.4 Changing the Oracle Net Listener Password........................................................................................... 17 3.2 Registering Information with a Non-default Listener....................................................................................... 18 3.3 Configuring a Naming Method ...................................................................................................................... 19 3.4 Listener Administration................................................................................................................................. 19 3.4.1 Determining the Current Status of a Listener .......................................................................................... 20 3.4.2 Using the Listener Control Utility to Determine the Listener Status........................................................... 20 3.4.3 Monitoring Services of a Listener ........................................................................................................... 20 4. Distributed Transactions Concepts ................................................................................................................ 21 4.1. What Are Distributed Transactions?............................................................................................................. 21 4.2. Managing a Distributed Database................................................................................................................ 22 4.2.1 Database Links...................................................................................................................................... 22 4.2.2. Why Use Database Links? .................................................................................................................... 24 4.2.3 Global Database Names in Database Links............................................................................................ 24 4.3. Types of Database Links............................................................................................................................. 25 4.4. Creating Database Links ............................................................................................................................. 26 4.4.1. Obtaining Privileges Necessary for Creating Database Links.................................................................. 26 4.4.2 Specifying Link Types ............................................................................................................................ 27 4.4.3 Specifying Link Users ............................................................................................................................ 27 4.4.4. Using Connection Qualifiers to Specify Service Names within Link Names ............................................. 28 4.5. Managing Database Links ........................................................................................................................... 29 4.5.1. Closing Database Links ........................................................................................................................ 29 4.5.2. Dropping Database Links...................................................................................................................... 29 4.5.3. Limiting the Number of Active Database Link Connections ..................................................................... 30 4.6. Viewing Information about Database Links................................................................................................... 30 5. Export and Import ........................................................................................................................................... 31 5.1. Export and Import Utilities ........................................................................................................................... 31 5.2. Before Using Export and Import................................................................................................................... 31 5.2.1. Running catexp.sql or catalog.sql.......................................................................................................... 31 5.2.2. Ensuring Sufficient Disk Space for Export Operations ............................................................................ 32 5.2.3. Verifying Access Privileges for Export and Import Operations................................................................. 32 5.3. Invoking Export and Import as SYSDBA ...................................................................................................... 32 5.4. Restrictions When Using Export's Interactive Method................................................................................... 33 5.5. Getting Online Help..................................................................................................................................... 34
INDEX
Page II of VIII
5.6. Importing Grants ......................................................................................................................................... 34 5.6.1. Grant Conditions................................................................................................................................... 34 5.7. Importing Objects into Other Schemas......................................................................................................... 34 5.7.1. Importing System Objects ..................................................................................................................... 34 5.7.2. Table Objects: Order of Import .............................................................................................................. 35 5.7.3. Importing into Existing Tables ............................................................................................................... 35 5.7.4. Disabling Referential Constraints........................................................................................................... 35 6. Data Pump....................................................................................................................................................... 37 6.1. Data Pump Components ............................................................................................................................. 37 6.2. How Does Data Pump Move Data? ............................................................................................................. 37 6.2.1. Using Data File Copying to Move Data .................................................................................................. 38 6.2.2. Using Direct Path to Move Data ............................................................................................................ 38 6.2.3. Situations in Which Direct Path Load Is Not Used .................................................................................. 38 6.2.4. Situations in Which Direct Path Unload Is Not Used............................................................................... 38 6.2.5. Using Network Link Import to Move Data............................................................................................... 39 6.3. Process during execution of a DATAPUMP job ............................................................................................ 39 6.3.1. Coordination of a Job............................................................................................................................ 39 6.3.2. Tracking Progress within a Job.............................................................................................................. 39 6.3.3. Filtering Data and Metadata during a Job .............................................................................................. 40 6.3.4. Transforming Metadata during a Job ..................................................................................................... 40 6.3.5. Maximizing Job Performance ................................................................................................................ 40 6.3.6. Loading and Unloading of Data ............................................................................................................. 40 6.3.7. Monitoring Job Status ........................................................................................................................... 40 6.3.8. Monitoring the Progress of Executing Jobs ............................................................................................ 41 6.4. File Allocation ............................................................................................................................................. 41 6.4.1. Specifying Files and Adding Additional Dump Files ................................................................................ 41 6.4.2. Default Locations for Dump, Log, and SQL Files.................................................................................... 41 6.5. Setting Parallelism ...................................................................................................................................... 43 6.6. Using Substitution Variables........................................................................................................................ 43 6.7. Moving Data between Different Database Versions...................................................................................... 43 6.8. Data Pump Export....................................................................................................................................... 44 6.8.1. Invoking Data Pump Export................................................................................................................... 44 6.8.2. Data Pump Export Interfaces ................................................................................................................ 44 6.8.3. Data Pump Export Modes ..................................................................................................................... 44 6.8.4. Filtering During Export Operations......................................................................................................... 45 6.9. Data Pump Import....................................................................................................................................... 46 6.9.1. Invoking Data Pump Import................................................................................................................... 46 6.9.2. Data Pump Import Interfaces................................................................................................................. 46 6.9.3. Data Pump Import Modes ..................................................................................................................... 47 7. Introduction to Backup and Recovery ............................................................................................................ 49 7.1. Purpose of Backup and Recovery................................................................................................................ 49 7.1.1. Data Protection..................................................................................................................................... 49 7.1.2. Media Failures...................................................................................................................................... 49 7.1.3. User Errors........................................................................................................................................... 50 7.1.4. Application Errors ................................................................................................................................. 50 7.1.5. Data Preservation ................................................................................................................................. 50 7.1.6. Data Transfer ....................................................................................................................................... 50 7.1.7. Recovery Manager (RMAN) .................................................................................................................. 50 7.1.8. User-managed backup and recovery ..................................................................................................... 50 7.2 Oracle Flashback Technology ...................................................................................................................... 51 7.3 Logical Flashback Features.......................................................................................................................... 52 7.3.1 Oracle Flashback Query ........................................................................................................................ 52 7.3.2 Oracle Flashback Version Query............................................................................................................ 52 7.3.3 Oracle Flashback Transaction Query...................................................................................................... 52 7.3.4 Oracle Flashback Transaction................................................................................................................ 52 7.3.5 Oracle Flashback Table ......................................................................................................................... 52 7.3.6 Oracle Flashback Drop .......................................................................................................................... 52 7.3.7 Flashback Database .............................................................................................................................. 52
INDEX
Page III of VIII
7.3.8 Data Recovery Advisor .......................................................................................................................... 53 8. User-Managed Database Backups .................................................................................................................. 54 8.1 Querying V$ Views to Obtain Backup Information ......................................................................................... 54 8.1.1 Listing Database Files before a Backup.................................................................................................. 54 8.1.2 Determining Datafile Status for Online Tablespace Backups ................................................................... 54 8.2 Making User-Managed Backups of the Whole Database ............................................................................... 55 8.2.1 Making Consistent Whole Database Backups......................................................................................... 55 8.3 Making User-Managed Backups of Tablespaces and Datafiles ...................................................................... 55 8.3.1 Making User-Managed Backups of Offline Tablespaces and Datafiles ..................................................... 55 8.3.2 Making User-Managed Backups of Online Tablespaces and Datafiles ..................................................... 56 8.3.3 Making User-Managed Backups of Online Read/Write Tablespaces........................................................ 56 8.3.4 Making Multiple User-Managed Backups of Online Read/Write Tablespaces ........................................... 57 8.3.6 Ending a Backup after an Instance Failure or SHUTDOWN ABORT........................................................ 58 8.3.7 Making User-Managed Backups of Read-Only Tablespaces ................................................................... 60 8.4 Making User-Managed Backups of the Control File ....................................................................................... 60 8.4.1 Backing up the Control File to a Binary File............................................................................................. 61 8.4.2 Backing up the Control File to a Trace File ............................................................................................. 61 8.5 Making User-Managed Backups of Archived Redo Logs ............................................................................... 61 9. Recovery Manager (RMAN)............................................................................................................................. 62 9.1 Overview of the RMAN Environment............................................................................................................. 62 9.2 Starting RMAN and Connecting to Database ................................................................................................ 62 Syntax of Common RMAN Command-line Options .......................................................................................... 63 9.3 Showing the Default RMAN Configuration..................................................................................................... 63 9.4 Backing up a Database ................................................................................................................................ 64 9.4.1 Backing up a Database in ARCHIVELOG Mode ..................................................................................... 64 9.4.2 Backing up a Database in NOARCHIVELOG Mode ................................................................................ 64 9.4.3 Typical Backup Options ......................................................................................................................... 64 9.4.4 Making Incrementally Updated Backups ................................................................................................. 65 9.5 Scripting RMAN Operations ......................................................................................................................... 66 9.6 Reporting on RMAN Operations ................................................................................................................... 66 9.6.1 Listing Backups ..................................................................................................................................... 67 9.6.2 Reporting on Database Files and Backups ............................................................................................. 67 9.7 Maintaining RMAN Backups......................................................................................................................... 68 9.7.1 Crosschecking Backups......................................................................................................................... 68 9.7.2 Deleting Obsolete Backups .................................................................................................................... 68 9.8 Diagnosing and Repairing Failures with Data Recovery Advisor .................................................................... 68 9.8.1 Listing Failures and Determining Repair Options..................................................................................... 68 9.8.2 Repairing Failures ................................................................................................................................. 69 9.8.3 Rewinding a Database with Flashback Database.................................................................................... 70 9.9 Restoring and Recovering Database Files .................................................................................................... 70 9.9.1 Preparing to Restore and Recover Database Files.................................................................................. 70 9.9.2 Recovering the Whole Database ............................................................................................................ 71 9.9.3 Recovering Tablespaces........................................................................................................................ 72 9.9.4 Recovering Individual Data Blocks ......................................................................................................... 72 10. Recovery Manager Architecture ................................................................................................................... 73 10.1 About the RMAN Environment.................................................................................................................... 73 10.2 RMAN Command-Line Client ..................................................................................................................... 74 10.3 RMAN Channels ........................................................................................................................................ 74 10.4 Channels and Devices ............................................................................................................................... 75 10.5 Automatic and Manual Channels ................................................................................................................ 75 10.6 RMAN Repository ...................................................................................................................................... 76 10.7 Media Management ................................................................................................................................... 76 10.8 RMAN Interaction with a Media Manager .................................................................................................... 76 10.9 Oracle Secure Backup ............................................................................................................................... 77 10.10 Backup Solutions Program ....................................................................................................................... 77 10.11 Flash Recovery Area................................................................................................................................ 77 10.12 RMAN in a Data Guard Environment ........................................................................................................ 77 10.12.1 RMAN Configuration in a Data Guard Environment ............................................................................. 77
INDEX
Page IV of VIII
10.12.2 RMAN File Management in a Data Guard Environment ....................................................................... 78 10.12.3 Interchangeability of Backups in a Data Guard Environment................................................................ 78 10.12.4 Association of Backups in a Data Guard Environment ......................................................................... 78 10.12.5 Accessibility of Backups in a Data Guard Environment........................................................................ 78 11. Starting and Interacting with the RMAN Client ............................................................................................. 79 11.1 Starting and Exiting RMAN......................................................................................................................... 79 11.2 Specifying the Location of RMAN Output .................................................................................................... 79 11.3 Entering RMAN Commands ....................................................................................................................... 80 11.3.1 Entering RMAN Commands at the RMAN Prompt................................................................................. 80 11.3.2 Using Command Files with RMAN........................................................................................................ 80 11.3.3 Entering Comments in RMAN Command Files...................................................................................... 80 11.3.4 Using Substitution Variables in Command Files .................................................................................... 81 11.4 Checking RMAN Syntax............................................................................................................................. 82 11.4.1 Checking RMAN Syntax at the Command Line ..................................................................................... 82 11.4.2 Checking RMAN Syntax in Command Files .......................................................................................... 82 11.4.3 Making Database Connections with RMAN........................................................................................... 84 11.4.4 Making RMAN Database Connections from the Operating System Command Line ................................ 85 11.4.5 Making Database Connections from the RMAN Prompt ........................................................................ 85 11.4.6 Connecting RMAN to an Auxiliary Database ......................................................................................... 86 11.4.7 Making RMAN Database Connections within Command Files ............................................................... 86 11.5 Diagnosing RMAN Connection Problems.................................................................................................... 87 11.5.1 Diagnosing Target and Auxiliary Database Connection Problems.......................................................... 87 11.5.2 Diagnosing Recovery Catalog Connection Problems............................................................................. 87 12. Configuring the RMAN Environment ............................................................................................................ 88 12.1 Configuring the Environment for RMAN Backups ........................................................................................ 88 12.2 Showing and Clearing Persistent RMAN Configurations .............................................................................. 88 12.3 Configuring the Default Device for Backups: Disk or SBT ............................................................................ 89 12.3.1 Configuring the Default Type for Backups: Backup Sets or Copies ........................................................ 89 12.4 Configuring Channels................................................................................................................................. 89 12.4.1 About Channel Configuration ............................................................................................................... 90 12.4.2 Configuring Channels for Disk .............................................................................................................. 90 12.4.3 Configuring Channel Parallelism for Disk and SBT Devices................................................................... 90 12.4.4 Manually Overriding Configured Channels ............................................................................................ 91 12.5 Configuring Control File & Server Parameter File Autobackups ................................................................... 91 12.5.1 Configuring the Control File Autobackup Format ................................................................................... 91 12.5.2 Overriding the Configured Control File Autobackup Format ................................................................... 92 12.6 Configuring RMAN to Make Backups to a Media Manager........................................................................... 92 12.6.1 Prerequisites for Using a Media Manager with RMAN ........................................................................... 93 12.6.2 Determining the Location of the Media Management Library ................................................................. 93 12.6.3 Configuring Media Management Software for RMAN Backups .............................................................. 93 12.6.4 Testing Whether the Media Manager Library Is Integrated Correctly ...................................................... 94 12.6.5 Testing Backup and Restore Operations on the Media Manager............................................................ 95 12.7 About Media Manager Backup Piece Names .............................................................................................. 95 12.8 Configuring Automatic SBT Channels ......................................................................................................... 96 12.9 Configuring the Flash Recovery Area.......................................................................................................... 96 12.9.1 Overview of the Flash Recovery Area................................................................................................... 96 12.9.2 Oracle Managed Files and Automatic Storage Management ................................................................. 96 12.9.3 How Oracle Manages Disk Space in the Flash Recovery Area .............................................................. 97 12.9.4 Enabling the Flash Recovery Area ....................................................................................................... 97 12.9.5 Considerations When Setting the Location of the Flash Recovery Area ................................................. 98 12.9.6 Setting the Flash Recovery Area Location and Initial Size ..................................................................... 99 12.9.7 Configuring Locations for Control Files and Redo Logs ......................................................................... 99 12.10 Configuring the Backup Retention Policy................................................................................................. 101 12.10.1 Configuring a Redundancy-Based Retention Policy........................................................................... 101 12.10.2 Configuring a Recovery Window-Based Retention Policy .................................................................. 101 12.10.3 Disabling the Retention Policy .......................................................................................................... 102 12.11 Configuring Backup Optimization............................................................................................................ 102 12.11.1 Overview of Backup Optimization ..................................................................................................... 102
INDEX
Page V of VIII
12.12 Configuring an Archived Redo Log Deletion Policy .................................................................................. 104 12.12.1. About Archived Redo Log Deletion Policies ..................................................................................... 104 12.12.2. When the Archived Redo Log Deletion Policy Is Disabled................................................................. 104 12.12.3. When the Archived Redo Log Deletion Policy Is Enabled ................................................................. 104 12.13 Configuring Oracle Flashback Database and Restore Points ................................................................... 105 12.13.1. About Restore Points and Flashback Database................................................................................ 105 12.13.2. Flashback Database ....................................................................................................................... 105 12.13.3 Normal Restore Points ..................................................................................................................... 106 12.13.4 Guaranteed Restore Points .............................................................................................................. 106 12.13.5 Logging for Flashback Database and Guaranteed Restore Points ..................................................... 107 12.13.6 Prerequisites for Flashback Database and Guaranteed Restore Points.............................................. 108 12.13.7 Enabling Flashback Database .......................................................................................................... 109 12.13.8 Creating Normal and Guaranteed Restore Points.............................................................................. 109 12.13.9 Configuring the Environment for Optimal Flashback Database Performance ...................................... 109 13. RMAN Backup Concepts............................................................................................................................. 111 13.1 Consistent and Inconsistent RMAN Backups............................................................................................. 111 13.1.1 Consistent Backups ........................................................................................................................... 111 13.1.2 Inconsistent Backups ......................................................................................................................... 111 13.2 Online Backups and Backup Mode ........................................................................................................... 111 13.3 Backup Sets ............................................................................................................................................ 112 13.3.1 Backup Sets and Backup Pieces........................................................................................................ 112 13.3.2 Compression for Backup Sets ............................................................................................................ 112 13.3.3 Encryption for Backup Sets ................................................................................................................ 112 13.3.4 Filenames for Backup Pieces ............................................................................................................. 113 13.3.5 Number and Size of Backup Pieces.................................................................................................... 113 13.3.6 Number and Size of Backup Sets ....................................................................................................... 113 13.3.7 Multiplexed Backup Sets.................................................................................................................... 113 13.3.8 Proxy Copies ..................................................................................................................................... 114 13.4 Image Copies .......................................................................................................................................... 115 13.4.1 RMAN-Created Image Copies ............................................................................................................ 115 13.4.2 User-Managed Image Copies............................................................................................................. 115 13.5 Multiple Copies of RMAN Backups ........................................................................................................... 116 13.5.1 Duplexed Backup Sets....................................................................................................................... 116 13.6 Backups of Backups................................................................................................................................. 116 13.6.1 Backups of Backup Sets .................................................................................................................... 116 13.6.2 Backups of Image Copies .................................................................................................................. 117 13.7 Control File and Server Parameter File Autobackups ................................................................................ 117 13.7.1 When RMAN Performs Control File Autobackups................................................................................ 117 13.7.2 How RMAN Performs Control File Autobackups.................................................................................. 117 13.8 Incremental Backups................................................................................................................................ 118 13.8.1 Multilevel Incremental Backups .......................................................................................................... 118 13.8.2 Differential Incremental Backups ........................................................................................................ 118 13.8.3 Cumulative Incremental Backups ....................................................................................................... 119 13.9 Block Change Tracking ............................................................................................................................ 119 13.10 Incremental Backup Algorithm ................................................................................................................ 119 13.11 Recovery with Incremental Backups ....................................................................................................... 120 13.12 Backup Retention Policies ...................................................................................................................... 120 13.12.1 Recovery Window............................................................................................................................ 121 13.12.2 Backup Redundancy........................................................................................................................ 121 13.12.3 Batch Deletes of Obsolete Backups.................................................................................................. 122 13.13 Backup Retention Policy and Flash Recovery Area Deletion Rules .......................................................... 122 14. Backing up the Database ............................................................................................................................ 123 14.1 Purpose of RMAN Backups...................................................................................................................... 123 14.2 Basic Concepts of RMAN Backups........................................................................................................... 123 14.3 Specifying Backup Output Options............................................................................................................ 123 14.3.1 Specifying the Device Type for an RMAN Backup ............................................................................... 123 14.3.2 Specifying Backup Set or Copy for an RMAN Backup to Disk .............................................................. 123 14.3.3 Specifying a Format for RMAN Backups............................................................................................. 124
INDEX
Page VI of VIII
14.3.4 Specifying Multiple Formats for Disk Backups..................................................................................... 124 14.4 Specifying Tags for an RMAN Backup ...................................................................................................... 125 14.4.1. About Backup Tags........................................................................................................................... 125 14.4.2. Specifying Tags for Backup Sets and Image Copies .......................................................................... 125 14.5 Making Compressed Backups .................................................................................................................. 126 14.6 Backing up Database Files with RMAN ..................................................................................................... 126 14.6.1 Making Whole Database Backups with RMAN .................................................................................... 126 14.6.2 Backing up Tablespaces and Datafiles with RMAN ............................................................................. 126 14.6.3 Backing up Control Files with RMAN .................................................................................................. 127 14.6.4 Making a Manual Backup of the Control File ....................................................................................... 127 14.6.5 Backing up Server Parameter Files with RMAN .................................................................................. 128 14.6.7 Backing up a Database in NOARCHIVELOG Mode ............................................................................ 128 14.6.8 Backing up Archived Redo Logs with RMAN....................................................................................... 128 14.6.9 Backing Up Only Archived Redo Logs That Need Backups ................................................................. 130 14.7 Making and Updating Incremental Backups .............................................................................................. 131 14.7.1 Purpose of Incremental Backups........................................................................................................ 131 14.7.2 Planning an Incremental Backup Strategy .......................................................................................... 131 14.7.3 Making Incremental Backups ............................................................................................................. 132 14.7.4 Incrementally Updating Backups ........................................................................................................ 132 14.8. Using Block Change Tracking to Improve Incremental Backup Performance............................................. 134 14.8.1. About Block Change Tracking ........................................................................................................... 134 14.8.2 Enabling and Disabling Block Change Tracking .................................................................................. 135 14.8.3 Disabling Block Change Tracking ....................................................................................................... 135 14.8.4 Checking Whether Change Tracking is Enabled ................................................................................. 135 14.8.5 Changing the Location of the Block Change Tracking File ................................................................... 136 14.9 Backing up RMAN Backups...................................................................................................................... 136 14.9.1. About Backups of Backups................................................................................................................ 136 14.9.2 Multiple Copies of Backup Sets .......................................................................................................... 137 14.9.3 Effect of a Backup Retention Policy on Backups of Backups ............................................................... 137 14.9.4 Backing Up Backup Sets with RMAN.................................................................................................. 138 14.9.5 Backing up Image Copy Backups with RMAN ..................................................................................... 139 15. Reporting on RMAN Operations ................................................................................................................. 140 15.1 Purpose of RMAN Reporting .................................................................................................................... 140 15.2 Basic Concepts of RMAN Reporting ......................................................................................................... 140 15.3 Listing Backups and Recovery-Related Objects ........................................................................................ 140 15.3.1. About the LIST Command................................................................................................................. 141 15.3.2 Listing Backups and Copies ............................................................................................................... 141 15.3.3 Listing Selected Backups and Copies ................................................................................................. 144 15.3.4 Listing Database Incarnations ............................................................................................................ 145 15.3.5 Listing Restore Points ........................................................................................................................ 146 15.3.6 Reporting on Backups and Database Schema .................................................................................... 146 15.3.7. Reporting on Files Needing a Backup under a Retention Policy.......................................................... 147 15.3.8. RMAN REPORT NEED BACKUP with Different Retention Policies..................................................... 147 15.3.9. Using RMAN REPORT NEED BACKUP with Tablespaces and Datafiles ............................................ 148 15.3.10. Using REPORT NEED BACKUP with Backups on Tape or Disk Only ............................................... 148 15.3.11. Reporting on Datafiles Affected by Unrecoverable Operations .......................................................... 148 15.3.12. Reporting on Obsolete Backups ...................................................................................................... 148 15.3.13. Reporting on the Database Schema ................................................................................................ 149 15.4 Using V$ Views to Query Backup Metadata .............................................................................................. 150 15.4.1 Querying Details of Past and Current RMAN Jobs .............................................................................. 150 15.4.2 Querying Recovery Catalog Views ..................................................................................................... 151 16. Managing a Recovery Catalog .................................................................................................................... 153 16.1 Purpose of the Recovery Catalog ............................................................................................................. 153 16.2 Basic Concepts for the Recovery Catalog ................................................................................................. 153 16.3 Database Registration.............................................................................................................................. 153 16.4 Centralization of Metadata in a Base Recovery Catalog ............................................................................ 153 16.5 Recovery Catalog Resynchronization ....................................................................................................... 154 16.6 Stored Scripts .......................................................................................................................................... 154
INDEX
Page VII of VIII
16.7 Planning the Size of the Recovery Catalog Schema.................................................................................. 154 16.8 Allocating Disk Space for the Recovery Catalog Database ........................................................................ 154 16.9 Creating the Recovery Catalog Schema Owner ........................................................................................ 155 16.9.1 Executing the CREATE CATALOG Command.................................................................................... 155 16.10 Registering a Database in the Recovery Catalog..................................................................................... 155 16.10.1 Registering a Database with the REGISTER DATABASE Command................................................. 156 16.11 Cataloging Backups in the Recovery Catalog.......................................................................................... 156 16.12 Creating and Managing Virtual Private Catalogs...................................................................................... 157 16.12.1 About Virtual Private Catalogs.......................................................................................................... 157 16.12.2 Creating and Granting Privileges to a Virtual Private Catalog Owner.................................................. 157 16.12.3 Creating a Virtual Private Catalog..................................................................................................... 158 16.12.4 Revoking Privileges from a Virtual Private Catalog Owner ................................................................. 158 16.12.5. Dropping a Virtual Private Catalog................................................................................................... 159 16.12.6. Protecting the Recovery Catalog ..................................................................................................... 159 16.12.7 Backing up the Recovery Catalog..................................................................................................... 159 16.12.7 Separating the Recovery Catalog from the Target Database ............................................................. 160 16.12.8 Exporting the Recovery Catalog Data for Logical Backups ................................................................ 160 16.12.9 Recovering the Recovery Catalog .................................................................................................... 160 16.13 Managing Stored Scripts ........................................................................................................................ 160 16.13.1 About Stored Scripts ........................................................................................................................ 160 16.13.2 Creating Stored Scripts .................................................................................................................... 161 16.13.3 Replacing Stored Scripts.................................................................................................................. 162 16.13.4 Executing Stored Scripts .................................................................................................................. 162 16.13.5 Creating and Executing Dynamic Stored Scripts ............................................................................... 163 16.13.6 Printing Stored Scripts ..................................................................................................................... 164 16.13.7 Listing Stored Script Names ............................................................................................................. 164 16.13.8 Deleting Stored Scripts .................................................................................................................... 164 16.13.10 Executing a Stored Script at RMAN Startup .................................................................................... 165 16.14 Maintaining a Recovery Catalog ............................................................................................................. 165 16.14.1 About Recovery Catalog Maintenance .............................................................................................. 165 16.14.2 Resynchronizing the Recovery Catalog ............................................................................................ 165 16.14.3 About Resynchronization of the Recovery Catalog ............................................................................ 165 16.14.4 Deciding When to Resynchronize the Recovery Catalog ................................................................... 165 16.14.5 Manually Resynchronizing the Recovery Catalog.............................................................................. 167 16.14.6 Updating the Recovery Catalog after Changing a DB_UNIQUE_ NAME ............................................ 167 16.14.7 Unregistering a Target Database from the Recovery Catalog ............................................................ 167 16.14.8 Resetting the Database Incarnation in the Recovery Catalog............................................................. 168 16.15 Recovery Catalog Imports ...................................................................................................................... 169 16.15.1 Prerequisites for Importing a Recovery Catalog ................................................................................ 170 16.15.2 Importing a Recovery Catalog .......................................................................................................... 170 16.16 Moving a Recovery Catalog.................................................................................................................... 170 16.17 Dropping a Recovery Catalog................................................................................................................. 170 17. RMAN Data Repair Concepts ...................................................................................................................... 172 17.1 Overview of RMAN Data Repair ............................................................................................................... 172 17.2 RMAN Data Repair Techniques................................................................................................................ 172 17.3 RMAN Restore Operations....................................................................................................................... 173 17.4 Backup Selection ..................................................................................................................................... 173 17.5 Restore Failover ...................................................................................................................................... 173 17.6 Restore Optimization................................................................................................................................ 174 17.7 RMAN Media Recovery............................................................................................................................ 174 17.8 Selection of Incremental Backups and Archived Redo Logs....................................................................... 174 17.9 Database Incarnations ............................................................................................................................. 174 18. Diagnosing and Repairing Failures............................................................................................................. 176 18.1 Purpose of Data Recovery Advisor ........................................................................................................... 176 18.2 Basic Concepts of Data Recovery Advisor ................................................................................................ 176 18.2.1 User Interfaces to Data Recovery Advisor........................................................................................... 176 18.2.2 Data Integrity Checks......................................................................................................................... 176 18.2.3 Failures ............................................................................................................................................. 177
INDEX
Page VIII of VIII
18.2.4 Manual Actions and Automatic Repair Options ................................................................................... 178 18.2.5 Supported Database Configurations ................................................................................................... 178 18.3 Basic Steps of Diagnosing and Repairing Failures .................................................................................... 179 18.3.1 Listing Failures .................................................................................................................................. 179 18.3.2 Listing All Failures.............................................................................................................................. 179 18.3.3 Listing a Subset of Failures ................................................................................................................ 180 18.4 Checking for Block Corruptions by Validating the Database....................................................................... 180 18.5 Determining Repair Options ..................................................................................................................... 182 18.6. Repairing Failures................................................................................................................................... 185 18.6.1. About Repairing Failures................................................................................................................... 185 18.6.2. Repairing a Failure ........................................................................................................................... 185 18.6.3 Changing Failure Status and Priority .................................................................................................. 187 19. Validating Database Files and Backups...................................................................................................... 189 19.1 Purpose of RMAN Validation .................................................................................................................... 189 19.2 Basic Concepts of RMAN Validation ......................................................................................................... 189 19.3 Checking for Block Corruption with the VALIDATE Command ................................................................... 189 19.4 Parallelizing the Validation of a Datafile .................................................................................................... 191 19.5 Validating Backups before Restoring Them............................................................................................... 192 20. Performing Complete Database Recovery.................................................................................................. 193 20.1 Purpose of Complete Database Recovery................................................................................................. 193 20.2 Preparing for Complete Database Recovery ............................................................................................. 193 20.3 Identifying the Database Files to Restore or Recover ................................................................................ 193 20.3.1 Identifying a Lost Control File ............................................................................................................. 193 20.3.2 Identifying Datafiles Requiring Media Recovery .................................................................................. 193 20.3.3 Determining the DBID of the Database ............................................................................................... 195 20.3.4 Previewing Backups Used in Restore Operations................................................................................ 195 20.3.5 Recalling Offsite Backups .................................................................................................................. 196 20.4 Validating Backups before Restoring Them............................................................................................... 197 20.4.1 Restoring Archived Redo Logs Needed for Recovery.......................................................................... 198 20.5 Performing Complete Database Recovery ................................................................................................ 198 20.5.1. About Complete Database Recovery................................................................................................. 198 20.5.2. Performing Complete Recovery of the Whole Database ..................................................................... 199 20.5.3 Performing Complete Recovery of a Tablespace ................................................................................ 201 20.5.4 Performing Complete Recovery of a Datafile after Switching to a Copy................................................ 204 21. Performing Block Media Recovery ............................................................................................................. 206 21.1 Purpose of Block Media Recovery ............................................................................................................ 206 21.2 Basic Concepts of Block Media Recovery ................................................................................................. 206 21.2.1 Identification of Corrupt Blocks........................................................................................................... 206 21.2.2 Missing Redo during Block Recovery.................................................................................................. 207 21.2.3 Prerequisites for Block Media Recovery.............................................................................................. 207 21.2.4 Recovering Individual Blocks.............................................................................................................. 207 21.2.5 Recovering All Blocks in V$DATABASE_BLOCK_CORRUPTION ....................................................... 208 22. Performing RMAN Tablespace Point-in-Time Recovery (TSPITR).............................................................. 209 22.1 Purpose of RMAN TSPTIR....................................................................................................................... 209 22.2 Basic Concepts of RMAN TSPITR............................................................................................................ 209 22.2.1 Basic Steps of RMAN TSPITR ........................................................................................................... 210 22.2.2 Special Considerations When Not Using a Recovery Catalog.............................................................. 211 22.3 Planning and Preparing for TSPITR.......................................................................................................... 211 22.3.1 Choosing the Right Target Time for TSPITR....................................................................................... 211 22.3.2 Determining the Recovery Set............................................................................................................ 212

Introduction To Oracle Net Services

Uploaded by

Copyright:

Available Formats

Introduction To Oracle Net Services

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Introduction To Oracle Net Services

Uploaded by

Copyright:

Available Formats

Introduction to Oracle Net Services

1. Introduction to Oracle Net Services

1.2.1 Client/Server Application Connections

1.2.2. Web Client Application Connections