2 Day DBA
11g Release 2 (11.2)
E10897-10
August 2012
Oracle Database 2 Day DBA 11g Release 2 (11.2)
E10897-10
Copyright © 2004, 2012, Oracle and/or its affiliates. All rights reserved.
Primary Author: Bert Rich
Contributing Author: Kathy Rich, Janet Stern, Steve Fogel, Colin McGregor, Lance Ashdown, Eric Belden, Craig Foch, Sushil Kumar, Roza Leyderman, Paul Needham, and Douglas Williams
Contributor: Bharat Baddepudi, Prasad Bagal, Timothy Chien, Benoit Dageville, Sudip Datta, Kakali Das, Mark Dilman, Prabhaker Gongloor, Shivani Gupta, Pat Huey, Chaitanya Koratamaddi, Balaji Krishnan, Vasudha Krishnaswamy, Rich Long, Venkat Maddali, Matthew McKerley, Ed Miner, Mughees Minhas, Saurabh Pandey, Kant Patel, Hanlin Chien, Mark Townsend, Xiaofang Wang, Kat Weill, and Mike Zampiceni
This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited.
The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing.
If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, the following notice is applicable:
U.S. GOVERNMENT END USERS: Oracle programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, delivered to U.S. Government end users are "commercial computer software" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations. As such, use, duplication, disclosure, modification, and adaptation of the programs, including any operating system, integrated software, any programs installed on the hardware, and/or documentation, shall be subject to license terms and license restrictions applicable to the programs. No other rights are granted to the U.S. Government.
This software or hardware is developed for general use in a variety of information management applications. It is not developed or intended for use in any inherently dangerous applications, including applications that may create a risk of personal injury. If you use this software or hardware in dangerous applications, then you shall be responsible to take all appropriate fail-safe, backup, redundancy, and other measures to ensure its safe use. Oracle Corporation and its affiliates disclaim any liability for any damages caused by use of this software or hardware in dangerous applications.
Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.
Intel and Intel Xeon are trademarks or registered trademarks of Intel Corporation. All SPARC trademarks are used under license and are trademarks or registered trademarks of SPARC International, Inc. AMD, Opteron, the AMD logo, and the AMD Opteron logo are trademarks or registered trademarks of Advanced Micro Devices. UNIX is a registered trademark of The Open Group.
This software or hardware and documentation may provide access to or information on content, products, and services from third parties. Oracle Corporation and its affiliates are not responsible for and expressly disclaim all warranties of any kind with respect to third-party content, products, and services. Oracle Corporation and its affiliates will not be responsible for any loss, costs, or damages incurred due to your access to or use of third-party content, products, or services.
As a database administrator (DBA), you are responsible for the overall operation of Oracle Database. This introductory chapter is intended to help orient you to many common DBA tasks, to the tools available to you, and to this guide. The chapter contains the following sections:
Oracle Database 2 Day DBA is a database administration quick start guide that teaches you how to perform day-to-day database administrative tasks. The goal of this guide is to help you understand the concepts behind Oracle Database, and to help you learn how to perform all common administrative tasks needed to keep the database operational. These tasks include configuring the database, managing memory and storage, managing users, managing database objects such as tables, performing basic troubleshooting, creating backups for your database, performance monitoring activities, and more.
The primary administrative interface used in this guide is Oracle Enterprise Manager Database Control, featuring all the self-management capabilities introduced in Oracle Database.
Oracle Database 2 Day DBA is task-oriented. The objective is to describe why and when administrative tasks must be performed. Where appropriate, it describes the concepts necessary to understand and complete a task, assuming the reader has no prior knowledge of the database. This guide is not an exhaustive discussion of all Oracle Database concepts. For this type of information, see Oracle Database Concepts.
Additionally, for a complete discussion of administrative tasks, see Oracle Database Administrator's Guide.
This guide is part of a comprehensive set of learning material for administering Oracle Database, which includes a 2 Day DBA Oracle By Example (OBE) series, available on the Web, and in an Oracle University instructor-led class.
Every chapter in Oracle Database 2 Day DBA has an associated Oracle By Example lesson. The OBE steps through all tasks in the chapter and includes annotated screenshots. In some cases, the OBE provides additional information to help you complete the task.
At the end of each chapter, you can find the link to its associated OBE lesson. The home page for the 2 Day DBA Oracle By Example series is as follows:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/2day_dba/index.html
In addition, Oracle University provides a related instructor-led course called Oracle Database 11g: 2 Day DBA. Contact Oracle University for more information.
Oracle Database is a relational database with object and Extensible Markup Language (XML) capabilities. In a relational database, all data is stored in two-dimensional tables that are composed of rows and columns. Oracle Database enables you to store data, update it, and efficiently retrieve it, with a high degree of performance, reliability, and scalability.
Oracle Database is composed of the following elements:
The Oracle software that you install on your host computer
The database, which is a collection of physical files on one or more disks
The database contains user data, metadata, and control structures. Metadata, or data about the data, is the collection of information on disk that permits Oracle software to manage user data. An example of metadata is the data dictionary. Control structures (such as the control file and online redo log files) ensure the integrity, availability, and recoverability of user data.
The Oracle instance, which is composed of the following:
Server processes that perform work on behalf of connected users and applications, and the memory and temporary storage used by these processes
Server processes parse and execute SQL statements, and retrieve and return results to the user or application.
Oracle Net, which is a software layer that enables client applications and Oracle Database to communicate over a network, and the Oracle Net listener, which is a process that listens for connection requests from the network.
|
See Also:
|
As an Oracle DBA, you can expect to be involved in the following tasks:
Installing Oracle software
Creating Oracle databases
Performing upgrades of the database and software to new release levels
Starting and shutting down the database instance
Managing the storage structures of the database
Managing users and security
Managing database objects, such as tables, indexes, and views
Backing up the database and performing recovery operations when necessary
Monitoring the state of the database and taking preventive or corrective action as required
Monitoring and tuning database performance
Diagnosing and reporting critical errors to Oracle Support Services
In a small to medium-sized database environment, you might be the sole person performing these tasks. In large, enterprise environments, the job is often divided among several DBAs, each of whom has a specialty, such as database security or database tuning.
The goal of this guide is to enable you to quickly and efficiently create an Oracle database, and to provide guidance in basic database administration.
The following are some products, tools, and utilities you can use to achieve your goals as a database administrator:
Oracle Universal Installer
Oracle Universal Installer (OUI) is a utility that installs your Oracle software and options. It can automatically start Oracle Database Configuration Assistant to install a database.
Oracle Database Configuration Assistant
Oracle Database Configuration Assistant (DBCA) is a utility that creates a database from templates that are supplied by Oracle, or you can create your own. It enables you to copy a preconfigured seed database, thus saving the time and effort of generating and customizing a new database.
Database Upgrade Assistant
The Database Upgrade Assistant is a tool that guides you through the upgrade of your existing database to a new Oracle Database release.
Net Configuration Assistant
Net Configuration Assistant (NETCA) is a utility that enables you to configure listeners and naming methods, which are critical components of the Oracle Database network.
Oracle Enterprise Manager Database Control
The primary product for managing your database is Oracle Enterprise Manager Database Control (Database Control), a Web-based interface. After you have installed the Oracle Database software, created or upgraded a database, and configured the network, you can use Database Control to manage your database. Database Control also provides an interface for performance advisors and for Oracle utilities such as SQL*Loader and Recovery Manager (RMAN).
Oracle also offers separately licensed Oracle Enterprise Manager management packs, management plug-ins, and other products you can purchase to enhance the capabilities of Oracle Enterprise Manager in specific environments.
This chapter introduces you to Oracle Database backup and recovery with Oracle Enterprise Manager Database Control. After reading this chapter, you should be familiar with the basic concepts of Oracle Database backup and recovery operations, know how to implement a disk-based backup strategy, and perform simple repairs to database files.
This chapter contains the following sections:
|
See Also:
|
The focus in Oracle Database backup and recovery is on the physical backup of database files, which permits you to reconstruct your database. The files protected by the backup and recovery facilities built into Oracle Enterprise Manager Database Control (Database Control) include data files, control files, server parameter files, and archived redo log files. With these files you can reconstruct your database. The backup mechanisms work at the physical level to protect against file damage, such as the accidental deletion of a data file or the failure of a disk drive.
Oracle Recovery Manager (RMAN), a command-line and Enterprise Manager-based tool, is the method preferred by Oracle for efficiently backing up and recovering your Oracle database. RMAN is designed to work intimately with the server, providing block-level corruption detection during backup and restore. RMAN optimizes performance and space consumption during backup with file multiplexing and backup set compression, and integrates with leading tape and storage media products.
Logical backups, such as exporting database objects such as tables or tablespaces, are a useful supplement to physical backups, but cannot protect your whole database. An effective backup strategy must be based on physical backups.
The Oracle Database flashback features provide a range of physical and logical data recovery tools as efficient, easy-to-use alternatives to physical and logical backups. The flashback features enable you to reverse the effects of unwanted database changes without restoring data files from backup or performing media recovery.
This section introduces the following flashback features:
Oracle Flashback Table, which enables you to revert a table to its contents at a time in the recent past
Oracle Flashback Drop, which enables you to retrieve deleted (dropped) database tables
Oracle Flashback Database, which enables you to revert the entire database to a past point in time
The first two features operate at the logical level, whereas the last feature operates at the physical level. None of the preceding features requires advance preparation such as creating logical exports to allow for retrieval of your lost data. You can use all of the features while your database is available. Oracle Database Backup and Recovery User's Guide discusses the flashback features of Oracle Database at greater length.
The Oracle Enterprise Manager physical backup and recovery features are built on the Recovery Manager (RMAN) command-line client. Database Control makes available many of the RMAN features, and provides wizards and automatic strategies to simplify and further automate RMAN-based backup and recovery.
To back up your database means to make copies of your data files, control file, and archived redo log files (if your database runs in ARCHIVELOG mode). Restoring a database means copying the physical files that comprise the database from a backup medium, typically disk or tape, to their original or to new locations. Database recovery is the process of updating database files restored from a backup with the changes made to the database after the backup, typically using online redo log files.
A backup is either consistent or inconsistent. To make a consistent backup, your database must have been shut down cleanly and remain closed for the duration of the backup. All committed changes in the online redo log files are written to the data files during the shut down process, so the data files are in a transaction-consistent state. When you restore your data files from a consistent backup, you can open the database immediately.
If the database is in ARCHIVELOG mode, then you can make inconsistent backups that are recoverable using archived redo log files. Open database backups are inconsistent because the online redo log files contain changes not yet applied to the data files. The online redo log files must be archived and then backed up with the data files to ensure recoverability.
Despite the name, an inconsistent backup is as robust a form of backup as a consistent backup. The advantage of making inconsistent backups is that you can back up your database while the database is open for updates.
|
See Also:
|
If you restore the archived redo log files and data files, then you must perform media recovery before you can open the database. Any database transactions in the archived redo log files not reflected in the data files are applied to the data files, bringing them to a transaction-consistent state before the database is opened.
Media recovery requires a control file, data files (typically restored from backup), and online and archived redo log files containing changes since the time the data files were backed up. Media recovery is most often used to recover from media failure, such as the loss of a file or disk, or a user error, such as the deletion of the contents of a table.
Media recovery can be a complete recovery or a point-in-time recovery. In a complete recovery, you restore backup data files and apply all changes from the archived and online redo log files to the data files. The database is returned to its state at the time of failure and can be opened with no loss of data.
In a point-in-time recovery, you return a database to its contents at a user-selected time in the past. You restore a backup of data files created before the target time and a complete set of archived redo log files from backup creation through the target time. Recovery applies changes between the backup time and the target time to the data files. All changes after the target time are discarded.
Oracle Enterprise Manager Database Control (Database Control) provides an interface to both a complete and a point-in-time recovery in the form of a Recovery wizard. However, this documentation focuses on complete recovery.
|
See Also:
|
To simplify the management of backup and recovery files, you can create a fast recovery area for your database. The fast recovery area is an Oracle-managed directory, file system, or Oracle Automatic Storage Management disk group that provides a centralized disk location for backup and recovery files. Oracle creates archived logs and flashback logs in the fast recovery area. RMAN can store its backup sets and image copies in the fast recovery area, and it uses it when restoring files during media recovery. The fast recovery area also acts as a disk cache for tape.
Oracle Database automatically manages this storage, deleting files that are no longer needed. Periodically copying backups to tape frees space in the fast recovery area for other files. Oracle recommends that you enable a recovery area to simplify backup management. Except as noted, this documentation assumes the use of a recovery area.
|
See Also:
|
RMAN maintains a record of database files and backups for each database on which it performs operations. This metadata is called the RMAN repository.
If you back up a file without using RMAN, such as by copying the file at the host operating system level, then you can add metadata about the copy to the RMAN repository. If you later use a command such as RESTORE DATABASE, then RMAN uses the records in the repository to select backups needed for the recovery.
The primary location for the RMAN repository for a database is its control file. The importance of this metadata for RMAN is one more reason why protecting your control file is a vital part of your backup strategy. In some installations, a second copy of the RMAN repository is stored in a schema called the recovery catalog. The recovery catalog is located in a separate database and can store metadata for multiple databases. Use of a recovery catalog is optional and is beyond the scope of this documentation.
|
See Also:
|
This section explains how to set up your database to take advantage of Oracle suggested backup strategies. If you configured the database for automated backups with the Oracle Database Configuration Assistant (DBCA), then skip this section.
To take maximum advantage of Oracle Database features that automatically manage backup and recovery files and operations, configure your database as follows:
Use a fast recovery area, which automates storage management for most backup-related files, and specify it as an archived redo log file destination.
Run the database in ARCHIVELOG mode so you can perform online backups and have data recovery options such as complete and point-in-time media recovery.
You must also set several policies governing which files are backed up, what format is used to store backups on disk, and when files become eligible for deletion.
This section contains the following topics:
Specifying Credentials for Backup and Recovery Using Database Control
Planning Space Usage and Location for the Fast Recovery Area
You must have the proper credentials to perform some configuration tasks for backup and recovery, and to schedule backup jobs and perform recovery. The following credentials may be required:
The Oracle Database user you specify when you log in to Oracle Enterprise Manager Database Control (Database Control)
The host operating system user whose credentials you provide when performing backup and recovery tasks
To enter credentials for backup and recovery tasks:
Log in to Database Control as a database user with SYSDBA privileges, or provide host operating system credentials for a user in the dba group on UNIX or Linux, or the ora_dba group on Microsoft Windows.
The host operating system user must also have execute permission for the RMAN command-line client.
|
Note: The host user may require certain host privileges to run background jobs such as database backups. For example, on UNIX and Linux, the host user must belong to the OSDBA group (typicallydba), and on Windows, the host user must be a member of the Administrators group and must be granted the Log on as batch job logon right. See your platform documentation for more information. |
For tasks requiring host operating system credentials, a Host Credentials form appears at the bottom of the page used to perform the task. Enterprise Manager uses the credentials when it starts RMAN jobs that you requested or scheduled.
Optionally, in the Host Credentials form, select Save as Preferred Credential.
If you select this option before performing your action, then the provided credentials are stored persistently for the currently logged-in Oracle Database user. The preferred credentials are reused by default whenever you log in as that user and perform operations requiring host credentials.
|
Note: In situations in which the database is shut down, you may still be prompted for host credentials even if you have saved the preferred credentials. |
You should place the fast recovery area on a separate disk from the working set of database files. Otherwise, the disk becomes a single point of failure for your database.
The amount of disk space to allocate for the fast recovery area depends on the size and activity levels of your database, which determine the size of your data files and online redo log files in addition to your recovery objectives. Your objectives dictate what kinds of backups you use, when you make them, and how long to keep them.
Space management in the fast recovery area is governed by a backup retention policy. A retention policy determines when files are obsolete, meaning that they are no longer needed to meet your data recovery objectives.
Retention policies can be based on redundancy of backups or on a recovery window (period of time). When using a policy based on redundancy, the fast recovery area considers a backup of a file obsolete only when the RMAN repository has records of a specified number of more recent backups of that file. When using a recovery policy based on a period of time (or window), you specify a time interval in days. Files are obsolete only when they are no longer needed for complete recovery or point-in-time recovery to a system change number (SCN) within the window. Therefore, a recovery retention policy based on a window is recommended.
Even after files in the fast recovery area are obsolete, they are typically not deleted until space is needed for new files. If space permits, files recently moved to tape remain on disk to avoid restoring them from tape for a recovery. The automatic deletion of obsolete files and files moved to tape from the fast recovery area makes it a convenient archiving destination. Other destinations require manual deletion of logs.
Oracle Database Backup and Recovery User's Guide explains how to size the fast recovery area. As a general rule, the larger the fast recovery area, the more useful it is. Ideally, the fast recovery area should be large enough for copies of the data files, control files, online redo log files, and archived redo log files needed to recover the database, and also the copies of these backup files that are kept based on the retention policy.
If your backup strategy includes incremental backups, which are described in "Incremental Backups of Data Files", then add enough space to the fast recovery area for these files. If you can move some backups to tape, then you can reduce the size of the fast recovery area. Note that retrieving files from tape causes longer database restore operations and recovery times.
In the Recovery Settings page, you can configure settings for instance recovery, media recovery, and fast recovery. In this section, you configure the fast recovery area and enable archiving for the database.
You can configure a fast recovery area when first creating the database. If you did not perform this task at database creation time, however, then you can create a fast recovery area for your database now.
To configure a fast recovery area and put the database in ARCHIVELOG mode:
On the host operating system, create a directory to hold the fast recovery area. If you are using Oracle ASM for your storage, then create a new disk group.
Make sure that the operating system permissions for the directory or disk devices allow the database to create files.
Log in to Enterprise Manager Database Control as user SYS.
On the Database Home page, click Availability to display the Availability subpage.
In the Backup/Recovery section, click Recovery Settings.
The Recovery Settings page appears.
Complete the following steps:
In the Media Recovery section, select ARCHIVELOG Mode.
If USE_DB_RECOVERY_FILE_DEST is not set as an archiving destination, then set it.
This initialization parameter indicates that the fast recovery area should be an archiving destination.
For ease of database management, the best practice is to use the fast recovery area as your only archiving destination.
In the Fast Recovery section, enter the path to the fast recovery area created in Step 1 in Fast Recovery Area Location, and select a value for Fast Recovery Area Size.
Select Enable Flashback Database.
This option specifies that the database should generate flashback logs in the fast recovery area, enabling you to use Flashback Database. During usual operation, the database occasionally logs images of data blocks to the flashback logs. The database automatically creates, deletes, and resizes flashback logs.
Ensure that the Apply initialization parameter changes to SPFILE only box is not selected.
Click Apply to save your changes.
A message prompts you to restart the database.
Click Yes.
The Restart Database: Specify Host and Target Database Credentials page appears.
Enter your host and database credentials, and then click OK.
See "Specifying Credentials for Backup and Recovery Using Database Control" for information about credentials.
On the Restart Database: Confirmation page, click Yes to begin the restart operations.
You can click Refresh periodically to monitor the progress of the operation.
Make a consistent (that is, offline) backup of your entire database immediately after switching your database to ARCHIVELOG mode.
|
Caution: You cannot use backups from before the switch toARCHIVELOG mode to restore and recover the database to a point in time after the switch. Thus, if you do not immediately make a backup after switching, then you are running your database without a valid backup. See "Performing and Scheduling Backups Using Database Control" to learn how to make database backups. |
|
See Also:
|
It is important to monitor space usage in the fast recovery area to ensure that it is large enough to contain backups and other recovery-related files.
To monitor available space in the fast recovery area:
In the High Availability section of the Database Home page, click the link next to Usable Fast Recovery Area (%).
The Recovery Settings page appears.
The Reclaimable Recovery Area (GB) and Free Recovery Area (GB) settings indicate how much space is available.
You can configure several backup-related settings and policies. For example, you can determine how backups are stored, which data is backed up, and how long backups are retained. You can also configure settings to optimize backup performance.
This section explains the concepts behind the available settings and also explains how to change them using the Backup Settings page in Database Control. The settings on the Device subpage affect how RMAN writes backups to disk and to tape.
Database backups created by RMAN are stored as image copies or backup sets.
Image copies are exact byte-for-byte copies of files. You can create an image copy by copying a file at the operating system level. Unlike copying files at the operating system level, however, image copies created through RMAN or Database Control are recorded in the RMAN repository so that RMAN can use these copies during database restore operations and recovery. RMAN can restore files only if they are recorded in the RMAN repository. RMAN can create image copies only on disk.
Backup sets are logical entities produced by the RMAN BACKUP command. This command can produce one or more backup sets on disk or media management devices. RMAN can write backup sets only to a media manager.
Each backup set contains several physical files called backup pieces. A backup piece stores the backup of one or more database files in a compact RMAN-specific format. One advantage of backup sets is that RMAN uses unused block compression to save space in backing up data files. Only those blocks in the data files that have been used to store data are included in the backup set.
RMAN depends on server sessions, processes that run on the database server, to create backups and restore them. Each server session, in turn, corresponds to an RMAN channel, representing one stream of data to or from a backup device. Channels are either of type disk or type SBT (tape).
RMAN supports parallelism, which is the use of multiple channels and server sessions to perform the work of one backup or recovery task. Proper use of parallelism can greatly increase performance on backup and recovery tasks.
|
See Also:
|
For disk-based backups, you can configure the default format for backups, the location on disk where backups are stored, and whether backup tasks run in parallel.
For tape backups, you can configure settings such as the number of tape drives and whether backups are compressed. On most platforms, you must integrate a media manager with the Oracle database to use sequential media for storage.
You can use Oracle Secure Backup, which supports both database and file system backups to tape, as your media manager. Oracle Secure Backup provides the same services for RMAN as other third-party SBT interfaces, but is better integrated with Database Control. This section assumes that you make only disk backups.
To configure backup settings for disk:
On the Database Home page, click Availability to display the Availability subpage.
In the Backup/Recovery section, click Backup Settings.
The Backup Settings page appears.
At the top of the page, click Device.
The Device subpage of Backup Settings appears.
Complete the following steps:
In Parallelism, enter 1.
Later, when you have had time to review the information in Oracle Database Backup and Recovery User's Guide about parallelism and performance in RMAN, you may want to change this value.
Leave the Disk Backup Location field blank so that RMAN directs backups to the fast recovery area.
In the Disk Backup Type section, select Backup Set.
One advantage of backup sets is that RMAN uses unused block compression to save space when backing up data files. Only those blocks in the data files that have been used to store data are included in the backup set.
In Host Credentials section at the bottom of the page, enter values in the Username and Password fields.
Host credentials are described in "Specifying Credentials for Backup and Recovery Using Database Control".
Click Test Disk Backup (near the top of the page) to ensure the credentials and backup location are correct.
A message appears that states whether the test was successful.
In this example you do not change the settings on the Backup Set subpages.
|
See Also:
|
You can set the backup policies that govern control file and server parameter file backups, tablespaces to exclude from an entire database backup, and the backup retention policy.
To configure the backup policy settings:
On the Database Home page, click Availability to display the Availability subpage.
In the Backup/Recovery section, click Backup Settings.
The Backup Settings page appears.
At the top of the page, click Policy.
The Backup Policy subpage appears.
Perform the following actions:
Select the Automatically backup the control file and server parameter file (SPFILE) with every backup and database structural change option. Leave the Autobackup Disk Location field blank so that RMAN stores the automatic backups in the fast recovery area.
The server parameter file and control file are critical to the database and RMAN, and are also relatively small compared to typical data files. Backing them up frequently results in relatively little storage overhead.
Select the Optimize the whole database backup by skipping unchanged files such as read-only and offline data files that have been backed up option.
This option saves space in the fast recovery area.
Select the Enable block change tracking for faster incremental backups option. Either leave the Block Change Tracking File field blank (if you specified Oracle Managed Files when creating the database) or enter a file name (including path).
This option takes advantage of the block change tracking feature, which greatly improves incremental backup performance at a small cost of overhead.
In the Tablespaces Excluded From Whole Database Backup section, leave the settings as they are.
This feature enables you to specify a list of tablespaces to exclude from a backup. For example, you do not have to include read-only tablespaces in every backup.
In the Retention Policy section, select Retain backups that are necessary for a recovery to any time within the specified number of days (point-in-time recovery). In Days, enter 31.
This setting enables a recovery policy with retention based on a period of time.
In the Archivelog Deletion Policy section, select None.
This option specifies that logs are eligible for automatic deletion only when they have been backed up to tape or are obsolete based on the retention policy.
At the bottom of the page, click OK to save your changes.
|
See Also:
|
This section describes how to back up your database with Oracle Enterprise Manager Database Control (Database Control). The Oracle suggested strategy for disk-only backups provides efficient daily backup of the database. This strategy enables you to quickly return your database to its state at any point during the previous 24 hours. For more flexible backup options, see Oracle Database Backup and Recovery User's Guide.
This section provides the concepts you need to understand the Oracle suggested backup strategy and other backup types provided through Database Control.
A full backup of a data file includes all used blocks of the data file. As explained in "About RMAN Backups", an RMAN backup can be either an image copy or backup set. An image copy is a bit-for-bit copy of the data file, and thus includes unused blocks.
RMAN incremental backups copy only those blocks in a data file that change between backups. A level 0 incremental backup, which copies all blocks in the data file, is used as a starting point for an incremental backup strategy.
Incremental backups at level 1 copy only images of blocks that have changed since a previous incremental backup. Level 1 backups can be cumulative, in which case all blocks changed since the most recent level 0 backup are included, or differential, in which case only blocks changed since the most recent level 0 or level 1 incremental backup are included. A typical incremental strategy makes level 1 backups at regular intervals such as once each day.
Recovering changed blocks from incremental backups can speed media recovery. Because an incremental level 1 backup copies the final contents of all data file blocks changed during the period covered by the incremental backup strategy, the recovery process can avoid reapplying updates from the archived redo log files of that period, and update each block with its final contents. The archived redo log files are used only for changes from the period not covered by level 1 backups.
RMAN enables you to apply level 1 incremental backups to an older image copy of your data files. You can roll forward the copy to the point in time of the most recent level 1 incremental backup. All blocks changed since the image copy was created are overwritten with their new contents as of the time of the last level 1 incremental backup. The effect is to roll forward the file in time, so that its contents are equivalent, for the purposes of database recovery, to an image copy of the data file made at the time of the last incremental level 1 backup.
Incorporating incrementally updated backups into your backup strategy shortens expected recovery times. Media recovery to the present time or to a point in time in the recent past can begin at the time of the last level 1 backup applied, rather than at the time of the last full database backup.
A tag is a text string that identifies that backup, either uniquely or as part of a group of backups. All RMAN backups, including incremental backups, are labeled with a tag. For example, if you performed a full database backup every Saturday, then you could use the tag FULL_SAT to identify this backup.
You can use tags to refer to specific backups in RMAN commands. For example, you could issue a command to move the latest FULL_SAT backup to tape. If you do not specify a tag, then RMAN creates a unique tag automatically.
Because you can use tags to refer to different groups of backups, you can create different routines in your backup strategy that do not interfere with each other. When you schedule a backup job and give the job a name, the job name is the tag.
Database Control enables you to perform RMAN backups and schedule backup jobs required by your backup strategy.
Whole backups of a database include the complete contents of all data files of the database, also the control file, archived redo log files, and server parameter file. With these files, you can perform a complete recovery.
While whole database backups can be an important element in your overall backup strategy, they are also a required step in some situations, such as when you enable or disable ARCHIVELOG mode (see "Configuring Recovery Settings"). This section explains how to make whole database backups to disk.
To perform a whole database backup when the database is open:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section of the Availability page, click Schedule Backup.
The Schedule Backup page appears.
In the Host Credentials section at the bottom of the page (not shown in the figure), enter values in the Username and Password fields if the Preferred Credentials are not set.
In the Customized Backup section, select Whole Database, and then click Schedule Customized Backup.
The Schedule Customized Backup: Options page appears.
In the Backup Type section, select Full Backup.
In the Backup Mode section, select either Online Backup or Offline Backup.
Typically, you want to perform online backups to maximize database availability.
|
Note: As explained in "Configuring Your Database for Basic Backup and Recovery", you can make online backups only if your database is running inARCHIVELOG mode. |
In the Advanced section, make the following selections, and then click Next:
If you are performing an online backup, then select Also back up all archived logs on disk.
You do not have to back up archived logs when performing an offline backup because the database is in a consistent state at the time of backup and does not require media recovery if you restore the database from this backup. However, you can choose to include archived logs in the backup.
If a fast recovery area is your only archiving destination, then do not select "Delete all archived logs from disk after they are successfully backed up".
In this case, archived redo log files that have been backed up are deleted automatically as space is needed. If you are using some other archiving destination, then it may be useful to select this option as part of managing your backup storage.
If the fast recovery area stores backups, then do not select the "Delete obsolete backups" option.
In this case, obsolete backups are deleted automatically as space is needed. If you use another destination for your backup files, then you can select this option.
Do not select "Use proxy copy supported by media management software to perform a backup" for now.
Do not enter a value in the Maximum Files per Backup Set field or the Section Size field.
The Schedule Customized Backup: Settings page appears.
Select Disk and then click Next.
Oracle recommends backing up to disk when possible to minimize recovery time by minimizing restore operations from tape. Later, you can move disk backups to tape.
The Schedule Customized Backup: Schedule page appears.
Complete the following steps:
In the Job section, leave the default values for Job Name and Job Description.
In the Job Name field, you can enter a user-specified tag for this backup. The job name is used as a prefix for the backup tag for backups created by this job.
|
Note: For recurring jobs, it is useful to set a Job Name so that the resulting backups are easy to identify as part of an ongoing series. Use a descriptive tag, such asWEEKLY_FULL_BACKUP. |
In the Job Description field, you can enter any descriptive text that is useful for your own reference.
In the Schedule section, select One Time (Immediately), and then click Next.
The Schedule Customized Backup: Review page appears.
Click Submit Job.
The Status page appears. This page should contain a message that indicates the job was successfully submitted.
Click View Job to monitor the progress of the backup.
The Execution page for your database appears. This page contains a Summary section describing the job. The table at the bottom of the page displays the progress of the various steps of the backup job. You can reload this page in your browser to monitor the ongoing progress of the job.
In the Name column of the table, you can see the current phase of the RMAN job. Clicking the name of the phase of the backup job displays a page containing the RMAN output for that part of the job. If you clicked on a job phase link, then from your current page, click the Execution: Database_name link at the top of the page to return to Execution page for your database.
To perform a whole database backup when the database is closed:
Follow the same steps as for an open database backup, except select Offline Backup in Step 5 and then continue with the steps that follow.
Database Control makes it easy to set up an Oracle suggested backup strategy for backups to disk that protects your data and provides efficient recoverability to any point in the user-specified recovery window (time period). The Oracle suggested strategy leverages the incremental backup and incrementally updated backup features to provide faster backups than whole database backups, and faster recoverability than is possible through applying database changes from the archive log to your data files.
The Oracle suggested strategy is based on creating an image copy of your database. The database rolls forward this copy by using incrementally updated backups. Oracle Enterprise Manager schedules RMAN backup jobs during the overnight hours.
For each data file, the strategy calls for backups as follows:
At the beginning of day 1 of the strategy (the time the first scheduled job actually runs), RMAN creates an incremental level 0 data file copy. It contains the data file contents at the beginning of day 1.
If a recovery is required, then the archived redo log files from day 1 can be used to recover to any point during day 1.
At the beginning of day 2, RMAN creates a differential incremental level 1 backup that contains the blocks changed during day 1.
If a recovery is required, then RMAN can apply this incremental level 1 to roll forward the level 0 backup to the beginning of day 2. RMAN can use archived redo log files to recover to any point during day 2.
At the beginning of each day n for day 3 and onward, RMAN applies the level 1 backup from the beginning of day n-1 to the level 0 backup. This action brings the data file copy to its state at the beginning of day n-1. Then, RMAN creates a new level 1 backup that contains the blocks changed during day n-1.
If a recovery is required, then RMAN can apply this incremental level 1 backup to the data file rolled forward on day n-1 to the beginning of day n. RMAN can use archived redo log files to recover the database to any point during day n.
In the Oracle suggested backup strategy, data file copies have the tag ORA$OEM_LEVEL_0. The differential level 1 incremental backups in this strategy share the same tag. You can safely implement other backup strategies without interfering with the Oracle suggested backup strategy.
Oracle suggested backup strategies also use tape backups in addition to disk backups, but these are beyond the scope of this section.
The following procedure schedules daily database backups. The strategy uses incremental backups and incrementally applied backups to enable quick recovery to any time in the preceding 24 hours.
To backup your database using the Oracle-suggested disk backup strategy:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section of the Availability page, click Schedule Backup.
The Schedule Backup page appears.
In the Oracle-Suggested Backup section, click Schedule Oracle-Suggested Backup.
The Schedule Oracle-Suggested Backup: Destination page appears. On this page, you select the destination media for the backup, which can be disk, tape, or both.
Select Disk and then click Next.
The Schedule Oracle-Suggested Backup: Setup page appears.
This page describes the backups that are performed each day as part of the disk-based strategy.
Review the information and then click Next.
The Schedule Oracle-Suggested Backup: Schedule page appears.
Choose a Start Date, Time Zone, and Daily Backup Time for the daily backups, and then click Next.
The Schedule Oracle-Suggested Backup: Review page appears.
Database Control displays the backup script that RMAN will run (although you cannot edit the script directly). The script should look similar to the following:
Daily Script:
run {
allocate channel oem_disk_backup device type disk;
recover copy of database with tag 'ORA_OEM_LEVEL_0';
backup incremental level 1 copies=1 for recover of copy with tag 'ORA_OEM_LEVEL_0' database;
}
Click Submit Job.
After taking some time to understand the full range of available backup options described in Oracle Database Backup and Recovery User's Guide you may decide to schedule backup tasks beyond those used to implement the Oracle suggested backup strategy.
To schedule miscellaneous backup tasks:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section of the Availability page, click Schedule Backup.
The Schedule Backup page appears.
In the Customized Backup section, select the object to back up. For example, select Tablespaces or Archivelogs.
Make sure the host credentials have been filled in, then click Schedule Customized Backup to start the Schedule Customized Backup wizard.
On the following pages of the wizard, specify details such as objects to back up, and required options and settings. Click Next on each page to proceed to the next page.
The choices presented on these pages are determined by the type of objects being backed up. For example, to backup a tablespace, on the first page of the wizard you would click the Add button to specify the tablespaces you want to include in the backup job. On the following pages, you would select the backup options, location, and schedule.
For more information about using the wizard, click Help on any page.
Click Submit Job.
As part of your backup strategy, you should periodically check whether your backups are intact and can be used to meet your recoverability objectives. You can validate your backups in the following ways:
Select specific backup sets or image copies in Database Control and validate them. This technique indicates if a backup exists and can be restored. For this form of validation, use the Manage Current Backups pages as described in "Validating Selected Backups".
Specify database files and let RMAN select backups to use when restoring those files, as it would for an actual restore operation. This technique ensures that your available backups are sufficient to restore the database. For this form of validation, use the Perform Recovery pages as described in "Validating Backups for Restore Operations".
|
Note: Validating backups stored on tape can be time-consuming because the entire backup is read from tape. |
You can set up both forms of validation as scheduled tasks in Database Control. You should incorporate both forms of validation into your backup strategy to ensure that your recoverability goals are met by your available backups.
Validating specific backups checks whether these backups exist and can be restored. It does not test whether the set of available backups meet your recoverability goals. For example, image copies of data files for several tablespaces from your database may exist, each of which can be validated. If there are some tablespaces for which no valid backups exist, however, then you cannot restore and recover the database.
To validate selected backups:
On the Database Home page, click Availability to display the Availability subpage.
In the Availability page, in the Manage section, click Manage Current Backups.
The Manage Current Backups page appears.
Select the check boxes next to each backup of interest in the list of current backups, and then click Validate.
The Validate: Specify Job Parameters page appears.
Specify a job name and description (or use the default values), and time settings for starting and repeating the operation. Click Submit Job.
A message confirms the submission of the job.
Click the View Job link to display details about the validation.
You can test whether a sufficient set of backups exists that can be used to restore the specified database files. After you specify which tablespaces to restore and, possibly, a time as of which to restore them, RMAN selects a set of backups that contain the needed data. RMAN reads the selected backups in their entirety to confirm that they are not corrupt, but does not produce output files.
Validating the restoration of files tests whether the file can be restored given the available backups, but it does not test whether all backups of the specified object are valid.
To verify whether specified database files can be restored:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section of Availability page, click Perform Recovery.
The Perform Recovery page appears.
In the User-Directed Recovery section, select Datafiles or Tablespaces from the Recovery Scope list, depending on what you want to validate.
For the Operation Type, select Restore Datafiles or Restore Tablespaces and then click Recover.
The Perform Object Level Recovery page appears.
Click Add to add tablespaces or data files for the validate operation. Select the data files or tablespaces to restore, then click Select. After making your selections, click Next.
The Perform Object Level Recovery: Restore page appears.
In the Backup Selection section, specify which backups should be restored. Typically you would select the most recent backup.
In the Backup Validation section, select Validate the specified backup without restoring the data files. Then, click Next.
The Perform Object Level Recovery: Schedule page appears.
The job to validate the backup runs immediately. You can specify a Job Name and Job Description, or use the default values. Click Next.
The Perform Object Level Recovery: Review page appears.
Click Submit Job to run the validation.
The Perform Recovery: Result page appears.
(Optional) Click View Job to see the results of the Backup Validation job.
|
See Also:
|
Backup reports contain summary and detailed information about past backup jobs run by RMAN, including both backups run through Oracle Enterprise Manager Database Control (Database Control) and the RMAN command-line client.
To display backup reports:
On the Database Home page, click Availability to display the Availability subpage.
In the Availability page, in the Manage section, click Backup Reports.
The Backup Reports page contains a list of recent backup jobs. You can use the Search section of the page to restrict (filter) the backups listed by the status of the job, the start time of the backup, and the type. In the Search sections, specify any filter conditions and click Go.
Click a link in the Backup Name column to display detailed information about any backup.
The Backup Report page is displayed for the selected backup. Use the Back button of your browser to return to the Backup Reports page.
Click the link in the Status column to view a log of RMAN output for the job.
|
Note: The control file viewV$RMAN_OUTPUT contains the output of recent RMAN jobs. The contents of this view are not preserved when the instance is restarted. Therefore, the output from past RMAN jobs may not be available. |
As part of a backup strategy, you must manage database backups. A related task is managing the record of those backups in the RMAN repository. Oracle Enterprise Manager Database Control (Database Control) simplifies these tasks.
An essential part of a backup and recovery strategy is managing backups after you create them. Backup management includes deleting obsolete backups and performing periodic checks to ensure that backups are available and usable.
You can perform backup management tasks from the Manage Current Backups page.
To display the Manage Current Backups page:
On the Database Home page, click Availability to display the Availability subpage.
In the Availability page, in the Manage section, click Manage Current Backups.
This page has two subpages: Backup Sets and Image Copies. Both pages have similar purposes: listing backups based on the record in the RMAN repository and enabling you to manage the backups.
A backup recorded in the RMAN repository has one of the following status values:
Available, meaning that the backup is still present on disk or tape, as recorded in the repository
Expired, meaning that the backup no longer exists on disk or tape, but is still listed in the repository
Unavailable, meaning that the backup is temporarily not available for data recovery operations (because, for example, it is stored on a tape that is stored offsite or on a disk that is currently not mounted)
Backups can also be obsolete. An obsolete backup is, based on the currently configured retention policy, no longer needed to satisfy data recovery goals.
Maintenance tasks that you can perform in Database Control include the following:
Viewing details about your backups
Cross-checking your repository, which means checking whether backups listed in the repository exist and are accessible, and marking as expired any backups not accessible at the time of the cross-check
Deleting the record of expired backups from your RMAN repository
Deleting obsolete backups from the repository and from the backup media
Validating backups to ensure that a given backup is available and not corrupted
|
Note: If a backup no longer exists, then immediately delete the backup record from the RMAN repository. Without an accurate record of available backups, you may discover that you no longer have complete backups of your database when you must perform a recovery. |
As with the backup and restore commands in Database Control, the commands to cross-check, delete, and change the status of backups are translated to RMAN commands. The commands are submitted as RMAN jobs that can be run immediately or be scheduled. Some tasks, such as periodic cross-checks of your backups, should be among the regularly scheduled components of your backup strategy.
If you use a fast recovery area for backup storage, then many maintenance activities are reduced or eliminated. The automatic disk space management mechanisms delete backups and other files as needed, thereby satisfying disk space demands for ongoing database operations without compromising the retention policy.
Cross-checking a backup synchronizes the physical reality of backups with their logical records in the RMAN repository. For example, if a backup on disk was deleted with an operating system command, then a cross-check detects this condition. After the cross-check, the RMAN repository correctly reflects the state of the backups.
Backups to disk are listed as available if they are still on disk in the location listed in the RMAN repository, and if they have no corruption in the file header. Backups on tape are listed as available if they are still on tape. The file headers are not checked for corruption. Backups that are missing or corrupt are listed as expired.
To cross-check individual files:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section, click Manage Current Backups.
The Manage Current Backups page appears.
Search for the backup sets or image copies whose contents you want to cross-check.
In the Results section, select each backup to be included in the cross-check operation.
Database Control does not support selecting both image copies and backup sets for a cross-check within a single operation.
Click Crosscheck at the top of the Results list.
A confirmation page is displayed. After you click Yes, Database Control performs the cross-check.
To cross-check all files:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section, click Manage Current Backups.
The Manage Current Backups page appears.
In the Manage Current Backups page, click Crosscheck All.
The Crosscheck All: Specify Job Parameters page appears. You can schedule the cross-check to run now or later, or specify regularly scheduled cross-checks.
Click Submit Job.
|
Note: Cross-checking all backups in the RMAN repository may take a long time, especially for tape backups. A cross-check of all files, unlike cross-checking individual files, is handled as a scheduled job. |
|
See Also:
|
Deleting expired backups removes from the RMAN repository those backups that are listed as EXPIRED. Expired backups are those found to be inaccessible during a cross-check. No attempt is made to delete the files containing the backup from disk or tape; this action updates only the RMAN repository.
To delete expired backups:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section, click Manage Current Backups.
The Manage Current Backups page appears.
In the Manage Current Backups page, click Delete All Expired.
This action deletes expired backup sets and expired image copies from the RMAN repository, regardless of which subpage is currently active.
The Delete All Expired: Specify Job Parameters page appears.
Optionally, select Perform the operation 'Crosscheck All' before 'Delete All Expired'.
By performing the cross-check immediately before deleting expired backups, RMAN has up-to-date information about which backups are expired.
Click Submit Job.
A message should appear indicating that your job was successfully submitted.
If one or more specific backups are unavailable because of a temporary condition, such as a disk drive that is temporarily offline or a tape stored offsite, then you can mark those backups as unavailable. RMAN does not use unavailable backups to restore or recover data.
|
Note: Backups stored in the fast recovery area cannot be marked as unavailable. |
RMAN keeps the record of unavailable backups in the RMAN repository and does not delete backups listed as unavailable when you delete expired backups. If the unavailable backups become accessible again, then you can mark them as available.
To mark backups as available or unavailable:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section, click Manage Current Backups.
The Manage Current Backups page appears.
In the Search section, find the backups whose status you want to change.
Click the Select check box next to each backup in the Results list of backups for which you want to change its availability.
Do one of the following:
Select Change to Available.
Select Change to Unavailable.
|
Note: If you restricted the backups listed by searching only for available backups, then only the Change to Unavailable button appears. If you restricted the backups listed by searching only for unavailable backups, then only the Change to Available button appears. |
A confirmation message appears.
Click Yes to perform the change operation.
This section explains how to delete obsolete backups, which are those no longer needed by the configured retention policy. If you use a fast recovery area as your only disk-based backup destination, then you never have to delete obsolete backups from disk. The fast recovery area keeps files as specified by the retention policy, and deletes them only when space is needed.
To delete obsolete backups:
On the Database Home page, click Availability to display the Availability subpage.
In the Manage section, click Manage Current Backups.
The Manage Current Backups page appears.
Click Delete All Obsolete.
All obsolete backups (both backup sets and image copies) are deleted, regardless of whether you clicked Delete All Obsolete while viewing the Backup Sets or Image Copies subpage.
The Delete All Obsolete: Specify Job Parameters page appears.
In the Schedule section, do one of the following:
Select One Time (Immediately) to run the deletion job immediately.
Schedule the deletion as you would a backup job.
Click Submit Job.
The Oracle advised recovery feature uses Data Recovery Advisor, which is an Oracle Database feature that automatically diagnoses data failures, determines and presents appropriate repair options, and performs repairs if requested by the user. By providing a centralized tool for automated data repair, Data Recovery Advisor improves the manageability and reliability of an Oracle database.
|
Note: To recover an Oracle RAC database using Data Recovery Advisor you must use the RMAN interface. You cannot use Enterprise Manager. |
In the context of Data Recovery Advisor, a health check is a diagnostic procedure run by the Health Monitor to assess the state of the database or its components. Health checks are invoked reactively when an error occurs. You can also invoke checks manually.
A failure is a persistent data corruption detected by a health check. Failures are usually detected reactively. A database operation involving corrupted data results in an error, which automatically invokes a health check in the database. The check searches the database for failures related to the error. If failures are diagnosed, then they are recorded in the Automatic Diagnostic Repository (ADR).
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. Data Recovery Advisor can report on and repair failures such as inaccessible files, physical and logical block corruptions, and I/O failures. Every failure has a failure priority: CRITICAL, HIGH, or LOW. Every failure also has a failure status of OPEN or CLOSED.
You can also use Data Recovery Advisor to view repair options. A repair is an action that fixes one or more failures. Examples of repairs include block media recovery, data file media recovery, and Oracle Flashback Database. Typically, Data Recovery Advisor presents both automated and manual repair options. If appropriate, you can choose an automated repair option in order to perform a repair. In this case, Data Recovery Advisor verifies the repair success, and closes the relevant repaired failures.
The recovery process begins when you either suspect or discover a failure. You can discover failures in many ways, including error messages, alerts, trace files, and health checks. You can then use Data Recovery Advisor to gain information and advice about failures and repair them automatically.
This section describes a scenario in which you use Data Recovery Advisor to repair a corrupted block. Assume that the Health Meter on the Database Home page indicates that an incident has occurred. The Alerts section of the page indicates that a block corruption has occurred.
To use the Oracle advised recovery strategy:
On the Database Home page, click Availability to display the Availability subpage.
Click Perform Recovery in the Manage section.
The Perform Recovery page appears. The Perform Recovery page is divided into two sections: Oracle Advised Recovery and User-Directed Recovery. The Oracle Advised Recovery section uses Data Recovery Advisor to automate recovery.
Look for failures in the Oracle Advised Recovery section.
In the screenshot shown in Step 2, the section indicates that one failure with high priority exists. The failure indicates that 1 or more data files are offline.
Do one of the following:
Click Advise and Recover.
Click the number next to the failure status.
The View and Manage Failures page appears.
In the Priority drop-down list, select All and then click Go.
This action enables you to view all failures known to Data Recovery Advisor. The data failures are represented as a navigation tree at the bottom of the page.
Perform the following actions:
Select Data Failures from the navigation tree to expand it (if it is not expanded).
Select the failure to expand it.
Click Advise.
The Recovery Advice page appears.
This page shows the RMAN script that is used to repair the failure. For example, for a corrupted block, the script might look similar to the following:
# block media recovery recover data file 1 block 63467;
Click Continue.
The Review page appears. This page summarizes the recovery job.
Click Submit Recovery Job.
The Job Activity page appears.
A table describes details of the repair such as the job name, the job status, the time that the repair is scheduled to be performed, the owner of the job, and so on.
Click the name of the repair job and click View Results.
The Job Run page appears.
You can click the job step in the navigation tree to view the results of the job.
Oracle Enterprise Manager Database Control (Database Control) User-Directed Recovery provides a Recovery wizard that enables you to use flashback features and perform restore operations and recovery procedures. For example, you can do the following:
Repair unwanted changes to database objects with the logical flashback features
Rewind the entire database with Oracle Flashback Database
Completely restore and recover the database
Perform point-in-time recovery of the database or selected tablespaces
Perform block media recovery of data files that have corrupted blocks
Database Control can determine which parts of the database must be restored and recovered, including detecting situations such as corrupted database files before they affect database operations. Database Control guides you through the recovery, prompting you for any required information and performing the specified recovery actions.
This section contains a few typical recovery examples so that you can become familiar with the Perform Recovery page. You can use the Perform Recovery page to access other whole database or object-level recovery features of Database Control.
Oracle Flashback Table enables you to rewind one or more tables back to their contents at a previous time without affecting other database objects. Thus, you can recover from logical data corruptions such as table rows added or deleted accidentally. Unlike point-in-time recovery, the database remains available during the flashback operation.
For this example, you use Flashback Table on the employees table in the hr schema. Assume that an erroneous update shortly after October 23, 2005 at 15:30:00 has changed the lastname column for all employees to an empty string, and you must return the original lastname values to the table.
Before you can use Flashback Table, you must ensure that row movement is enabled on the table to be flashed back, or returned to a previous state. Row movement indicates that rowids will change after the flashback occurs. This restriction exists because if rowids before the flashback were stored by an application, then there is no guarantee that the rowids will correspond to the same rows after the flashback.
To enable row movement on a table:
On the Database Home page, click Schema to display the Schema subpage.
Click Tables in the Database Objects section.
The Tables page appears.
To find the target table for Flashback Table, do the following:
Enter the schema name in the Schema field and, optionally, the table name in the Object Name field.
Click Go to search for the table.
When you search for tables, for example, in the hr schema, you may have to page through the search results to find your table.
Select the table from the list of tables and click Edit.
In this scenario, select employees.
The Edit Table: table_name page appears.
Click Options to go to the Options subpage.
Complete the following steps:
Set Enable Row Movement to Yes.
Click Apply to update the options for the table.
An update message appears.
Complete the following steps:
Click Tables at the top of the page to return to the search results.
Enable row movement on more tables by repeating Step 1 through Step 6 for each table.
For this example, you should also enable row movement on the tables hr.jobs and hr.departments.
In this example, you rewind the hr.employees table and its dependent tables to a previous point in time.
To perform the Flashback Table operation:
On the Database Home page, click Availability to display the Availability subpage.
Select Perform Recovery from the Manage section.
The Perform Recovery page appears.
In the User Directed Recovery section, select Tables from the Recovery Scope list.
The page reloads with options appropriate for object-level recovery of tables.
For Operation Type, choose Flashback Existing Tables, and click Recover.
The Perform Object Level Recovery: Point-in-time page appears.
Choose the target time for the Flashback Table operation, and click Next.
|
Note: If you do not know the time at which the unwanted changes occurred, then you can investigate the history of transactions affecting this table by selecting Evaluate row changes and transactions to decide upon a point in time. Oracle Flashback Version Query enables you to review all recent changes to the target table. Use of this feature is beyond the scope of this documentation. |
For this example, assume that rows were accidentally inserted 5 minutes ago. Select Flashback to a timestamp and enter a time 5 minutes before now.
The Perform Object Level Recovery: Flashback Tables page appears.
Enter table names in the Tables to Flashback text box and then click Next.
You can enter multiple table names to flash back several tables to the same time. You can also click Add Tables and search for more tables. For this example, enter the text hr.employees in the Tables to Flashback text box.
If your table has other dependent tables, then the Dependency Options page appears. This page asks how dependencies should be handled.
Do one of the following, and then click Next:
Select Cascade to flash back any dependent tables.
Select Restrict to flash back only the target table.
Select Customize to choose which dependent tables to flash back and which to leave as they are.
You can click Show Dependencies to see which tables will be affected.
|
Note: Row movement must be enabled on all affected tables, not just the initial target tables. |
In this example, the hr.employees table has dependent tables hr.jobs and hr.departments, so select Cascade and then click Next.
The Perform Object Level Recovery: Review page appears.
Click Submit.
When the operation is completed, a Confirmation page displays the results. Click OK.
Oracle Flashback Drop enables you to reverse the effects of dropping (deleting) a table, returning the dropped table to the database along with dependent objects such as indexes and triggers. This feature stores dropped objects in a recycle bin, from which they can be retrieved until the recycle bin is purged, either explicitly or because space is needed.
As with Flashback Table, you can use Flashback Drop while the database is open. Also, you can perform the flashback without undoing changes in objects not affected by the Flashback Drop operation. Flashback Table is more convenient than forms of media recovery that require taking the database offline and restoring files from backup.
|
Note: For a table to be recoverable using Flashback Drop, it must reside in a locally managed tablespace. Also, you cannot recover tables in theSYSTEM tablespaces with Flashback Drop, regardless of the tablespace type. |
For the purpose of learning about Flashback Drop, you will create a new table named reg_hist and then drop it. The database places the table in the recycle bin so that it can be retrieved with the Flashback Drop feature.
To create and then drop a table:
On the Database Home page, click Schema to display the Schema subpage.
Click Tables.
The Tables page appears.
Enter hr in the Schema field and regions in the Object Name field. Click Go.
The schema and table are listed in the table at the bottom of the page.
In the Actions list, select Create Like and click Go.
The General subpage of the Create Table page appears.
Complete the following steps:
In the Name field, enter reg_hist.
Deselect Not Null for the REGION_ID column.
Click Constraints to open the Constraints subpage.
The Constraints subpage appears.
Select each constraint and click Delete.
Click OK to create the table.
A confirmation message appears.
In the Object Name field, enter reg_hist and click Go.
The Tables page displays information about this table.
Click Delete with Options to delete the table.
The Delete With Options page appears.
Select Delete the table definition, all its data, and dependent objects (DROP), and then click Yes.
A message confirms that the table was deleted.
This section assumes that you created and then dropped the reg_hist table, as described in "Dropping a Table". The following procedure retrieves reg_hist from the recycle bin.
To perform the Flashback Drop operation:
On the Database Home page, click Availability to display the Availability subpage.
Click Perform Recovery in the Backup/Recovery section.
The Perform Recovery page appears.
In the User-Directed Recovery section, select Tables from the Recovery Scope list.
The page reloads with options appropriate for object-level recovery of tables.
Select Flashback Dropped Tables for the Operation Type, and then click Recover.
The Perform Object Level Recovery: Dropped Objects Selection page appears.
Search among the dropped objects in the recycle bin for the objects to retrieve.
For this example, enter hr in the Schema Name field and reg_hist in the Table field, and click Go.
The Results section lists the objects matching your search. If needed, click the arrow next to Recycle Bin to expand its contents by one level, showing dropped tables matching your search but not their dependent objects.
Select each table to retrieve using Flashback Drop.
For this example, select reg_hist and then click Next.
|
Note: When a table is retrieved from the recycle bin, all the dependent objects for the table that are in the recycle bin are retrieved with it. They cannot be retrieved separately. |
The Perform Object Level Recovery: Rename page appears.
If needed, enter new names for dropped objects that you are retrieving. For this scenario, do not specify a new name. Click Next.
The primary reason for renaming objects when you retrieve them from the recycle bin is because you might have created new tables with the same names as tables being retrieved. If you must rename some objects, then enter new names as needed in the New Name field.
The Perform Object Level Recovery: Review page appears. This page displays an impact analysis, showing the full set of objects to be flashed back, including the dependent objects, and the names they will have when the Flashback Drop operation is complete.
Review the changes and then click Submit.
A confirmation page should indicate the success of the operation.
Click OK to return to the Availability page.
Unlike the other flashback features, Oracle Flashback Database operates at a physical level. When you use Flashback Database, your current data files revert to their contents at a previous time. The result is similar to database point-in-time recovery, but Flashback Database can be much faster because it does not require you to restore and recover data files. Also, Flashback Database requires limited application of redo data as compared to media recovery.
Flashback Database uses flashback logs to access previous versions of data blocks and also uses some data in the archived redo log files. To have the option of using Flashback Database to repair your database, you must have configured the database to generate flashback logs as explained in "Configuring Recovery Settings".
To perform a Flashback Database operation:
On the Database Home page, click Availability to display the Availability subpage.
Click Perform Recovery.
The Perform Recovery page appears.
In the User-Directed Recovery section, select Whole Database.
Select Recover to the current time or a previous point-in-time.
If necessary, provide the host computer credentials.
Click Recover.
A Confirmation page appears.
Click Yes to confirm the shutdown of the database.
The Recovery Wizard page appears. At this point, the shutdown begins.
When the database is shut down and brought to the mounted state, Database Control is also shut down briefly and restarted. During this process, there is a period during which Database Control cannot respond to your browser. Refresh the page until Database Control responds again.
When Database Control has restarted and the database is being started and mounted, Database Control may also briefly report that the database is in the NOMOUNT state. You are given the choices Refresh, Startup, and Perform Recovery. Refresh the page periodically until the Database Instance page reports that the database instance is mounted before you proceed.
Click Perform Recovery to resume your recovery session.
If you are prompted for host computer and database credentials, then connect with the SYSDBA privilege, or provide host computer credentials for a user in the DBA group.
See "Specifying Credentials for Backup and Recovery Using Database Control" for information about credentials.
When the Perform Recovery page is displayed again, it shows that the database is mounted, which is required to restore and recover the entire database.
In the User-Directed Recovery section, select Whole Database.
Select Recover to the current time or a previous point-in-time.
If necessary, provide the host credentials.
Click Recover.
A Confirmation page appears.
Complete the following steps:
Select Recover to a prior point-in-time.
In the Date field, select a time 5 minutes before now.
Click Next.
The Perform Whole Database Recovery: Flashback page appears.
Select Yes to use Flashback Database and then click Next.
The Perform Whole Database Recovery: Review page appears.
Review the options that you selected and click Submit.
When the flashback operation completes, the Perform Recovery: Result page appears.
Click Open Database.
After the database has opened successfully, click OK.
This section demonstrates how to restore and recover the entire database. This example assumes that you are restoring and recovering your database after the loss of one or more data files, but you still have a usable server parameter file and control file. You can also use Database Control to restore a lost server parameter file or control file.
To restore and recover the entire database:
Perform Step 1 through Step 7 from the procedure in "Rewinding a Database Using Oracle Flashback Database".
Do one of the following:
Select Recover to the current time to recover all transactions to your database up until now.
Select Recover to a prior point-in-time to recover transactions only up through some point in time in the past.
For this example, select Recover to the current time, and then click Next.
The Perform Whole Database Recovery: Rename page appears.
Select No to restore the files to their default locations, and then click Next.
The Perform Whole Database Recovery: Review page appears.
Click Submit to start the restoration and recovery of the database.
|
Note: In some repair scenarios, such as a complete restoration and recovery of your database, the database state is altered by steps you take while using the wizard. Database Control displays warnings each time a significant database change results from selecting Continue during the recovery process. Pay close attention to these warnings. |
When the recovery completes, the Perform Recovery: Result page appears.
Click Open Database and then OK.
|
See Also:
|
Oracle By Example (OBE) has a series on the Oracle Database 2 Day DBA guide. This OBE steps you through the tasks in this section, and includes annotated screenshots. To view the Backup and Recovery OBE, in your browser, enter the following URL:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/2day_dba/backup/backup.htm
This chapter describes how to keep your Oracle Database software up-to-date. It contains the following sections:
Software management involves keeping your Oracle Database software up-to-date with the latest product fixes. When a product defect, or a bug, is discovered, a patch is created to fix the problem. A patch corrects a single defect in the installed software. Individual patches, also referred to as interim patches, are made available to customers who for business reasons cannot wait until the next patch set to receive the product fix.
Oracle periodically issues maintenance releases for its software, in the form of patch sets. A patch set is a collection of product fixes that have been released up to the time of the maintenance release. Patch sets are fully tested and integrated product fixes. All the product fixes in the patch set have been tested and are certified to work with each other.
Every patch or patch set is associated with a bug number for identification purposes. Patch sets are also associated with version numbers. For example, if you use Oracle Database 11g Release 11.1.0.6, then an available patch set might be 11.1.0.7. The version number of the patched software does not change if an interim patch is applied.
Every patch has an associated README file that describes how it fixes the software. The README file also has instructions for applying the patch.
Every patch set is accompanied by a Patch Set Notes file that contains installation instructions and information about the product fixes contained within the patch set. When you apply a patch set to your Oracle software, you change the maintenance release number for your installed software. Applying a patch set affects the software residing in your Oracle home only, with no change to the data in the database.
You can use Oracle OPatch and Oracle Universal Installer to apply patches and patch sets respectively. Alternatively, you can automate the application of these patches using Oracle Enterprise Manager Grid Control. Use of these products is beyond the scope of this documentation.
Use Database Upgrade Assistant (DBUA) to upgrade an existing database to the current release of Oracle Database.
This section contains these topics:
Database Upgrade Assistant (DBUA) guides you through the upgrade process and configures your database for the new release. DBUA automates the upgrade process and makes appropriate recommendations for configuration options such as tablespaces and online redo log files.
DBUA can be used to upgrade databases created using any edition of the Oracle Database software, including Express Edition (XE) databases.
Pre-Upgrade Checks
DBUA does not begin the upgrade until it completes all of the following pre-upgrade steps:
Checks for any invalid user accounts or roles
Checks for any invalid data types or invalid objects
Checks for any desupported character sets
Checks for adequate resources, including rollback segments, tablespaces, and free disk space
Checks for any missing SQL scripts needed for the upgrade
Backs up all necessary files (optional)
Automated Upgrade Tasks
After completing the pre-upgrade steps, DBUA automatically performs the following tasks:
Modifies or creates new required tablespaces
Invokes the appropriate upgrade scripts
Archives the online redo log files
Disables archiving during the upgrade phase (to improve performance)
While the upgrade is running, DBUA shows the upgrade progress for each component. DBUA writes detailed trace and log files and produces a complete HTML report for later reference. To enhance security, DBUA automatically locks new user accounts in the upgraded database. DBUA then proceeds to create new configuration files (initialization parameter and listener files) in the new Oracle home.
Support for Oracle Real Application Clusters
DBUA is fully compliant with Oracle Real Application Clusters (Oracle RAC) environments. In Oracle RAC environments, DBUA upgrades all database and configuration files on all nodes in the cluster.
About Upgrading Oracle Automatic Storage Management
Oracle ASM Configuration Assistant (ASMCA) enables you to upgrade an existing Oracle ASM instance to the current software level. However, the recommended practice is to upgrade an Oracle ASM instance with Oracle Universal Installer (OUI). OUI automatically defaults to upgrade mode when it detects an Oracle ASM instance at a previous release level.
|
See Also:
|
Support for Silent Mode
DBUA supports a silent mode of operation in which no user interface is presented to the user. Silent mode enables you to use a single statement for the upgrade.
DBUA supports the following versions of Oracle Database for upgrading to Oracle Database 11g Release 2 (11.2):
Oracle9i Release 2 (9.2.0.6) and beyond
Oracle Database 10g release 1 (10.1)
Oracle Database 10g release 2 (10.2)
Oracle Database 11g release 1 (11.1)
If your database version is not in this list, then you must upgrade first to the closest release listed. You can then upgrade the database to Oracle Database 11g release 2 (11.2).
If you install the Oracle Database software only and specify that you are upgrading an existing database to the new Oracle Database release, then DBUA is launched automatically after the software installation. You can then continue as described in "Upgrading a Database Using DBUA".
If you perform a software-only installation and do not upgrade your database at that time, then you can do so later by launching DBUA.
Be aware of the following before you begin using DBUA:
You must run Net Configuration Assistant (NETCA) before running DBUA.
It is not possible to upgrade a database with DBUA when the source and target Oracle homes are owned by different users.
If the database instance is not running, then DBUA tries to start the instance with the default initialization parameter file. If that fails, then you are prompted to provide the name of the correct initialization parameter file or to start the instance. If the instance is up and running, then DBUA connects to it.
If you stop the upgrade, but do not restore the database, then you should not restart DBUA until you start the database instance in UPGRADE mode using the Oracle Database 11g release 2 (11.2) software. You cannot go back to the original software version unless you restore your database.
If you restore your database manually (not using DBUA), then remove the following file from the Oracle Database 11g release 2 (11.2) home directory before starting DBUA:
$ Oracle_home/cfgtoollogs/dbua/logs/Welcome_SID.txt
The presence of this file indicates to DBUA that this operation is a reattempt of a previous operation.
To start DBUA on Microsoft Windows:
Configure the operating system environment variables, as described in "Configuring the Operating System Environment Variables".
Click Start, then select Programs (or All Programs)
Select Oracle - HOME_NAME
Select Configuration and Migration Tools
Select Database Upgrade Assistant
The Database Upgrade Assistant: Welcome window appears.
To start DBUA on any supported platform:
Open a command window.
Configure the operating system environment variables, as described in "Configuring the Operating System Environment Variables".
Enter the following command:
dbua
The Database Upgrade Assistant: Welcome window appears.
|
Note: Thedbua executable is typically found in your Oracle_home/bin directory. |
Complete the following steps to upgrade a database using DBUA. If you need help at any window or want to consult more documentation about DBUA, then click the Help button to access the online Help.
To upgrade a database using DBUA:
Start DBUA. See "Starting DBUA".
At the Welcome window of DBUA, make sure the database being upgraded meets the specified conditions. Then, click Next.
At the Databases window, select the database you want to upgrade from the Available Databases table. Then, click Next.
You can select only one database at a time. If you run DBUA from a user account that does not have SYSDBA privileges, then enter the user name and password credentials to enable SYSDBA privileges for the selected database.
DBUA displays a message saying it is getting database information. DBUA analyzes the selected database, performing pre-upgrade checks and displaying warnings as necessary:
It checks for any online redo log files of a size less than 4 megabytes (MB). If such files are found, then DBUA gives the option to drop or create new online redo log files.
It checks the initialization parameter file for any obsolete or deprecated initialization parameters.
If no problems are found, then the Diagnostic Destination window appears.
In the Diagnostic Destination field, do one of the following:
Leave the setting at its default value, which is the Oracle base directory.
Enter a new destination.
Click Browse and select a new destination.
Diagnostic Destination is the default location to store Oracle trace and diagnostic files. It replaces the initialization parameter settings for background dump destination, user dump destination and core dump destination from earlier Oracle Database releases.
Click Next.
The Move Database Files window appears.
Do one of the following:
Select Do Not Move Database Files as Part of Upgrade.
Select Move Database Files During Upgrade.
If you choose to move database files, then you must also select either File System or Oracle Automatic Storage Management (Oracle ASM).
Click Next.
The Recompile Invalid Objects window appears.
(Optional) Select Recompile invalid objects at the end of upgrade and modify the value of degree of parallelism.
When you upgrade your database to the new Oracle Database release, many of the PL/SQL modules in the database become invalid. By default, Oracle Database recompiles invalid PL/SQL modules as they are used, but this takes time and can result in poor performance. To eliminate these performance issues, select Recompile invalid objects at the end of upgrade. All the invalid PL/SQL modules are be recompiled immediately after the upgrade is performed. The task of recompiling all the invalid PL/SQL modules in your database can take a significant amount of time and increase the time it takes to complete your database upgrade.
If you have multiple CPUs, then DBUA automatically adds a Degree of Parallelism menu to the Recompile Invalid Objects window. Parallel processing reduces the time it takes to recompile all the invalid PL/SQL modules in your database. DBUA automatically sets the degree of parallelism to one less than the number of available CPUs. You can select a different value from the menu.
|
Note: Selecting Recompile invalid objects at the end of upgrade is equivalent to running the/rdbms/admin/utlrp.sql script, which is used to recompile stored PL/SQL and Java code. |
Click Next.
The Backup window appears.
Select one of the following options:
I have already backed up my database.
I would like this tool to back up the database.
If you use DBUA to back up your database, then DBUA makes a copy of all database files in the directory that you specify in the Backup Directory field. DBUA performs this consistent backup automatically after it shuts down the database and before it begins the upgrade process. The backup does not compress the database files.
In the Backup Directory field, do one of the following:
Leave the setting at its default value
Enter a different valid file system path. You cannot specify a raw device for the backup files.
Click Browse and select a new backup destination.
Oracle strongly recommends that you back up your database before starting the upgrade. If errors occur during the upgrade, then you may need to restore the database from the backup.
In addition to creating a backup of your database, DBUA creates an executable script in the directory specified in the Backup Directory field. If needed, you can use the executable script appropriate to your system to restore the database files:
Microsoft Windows: db_name_restore.bat
Linux or UNIX systems: db_name_restore.sh
Click Next.
The Recovery Configuration window appears.
In the Fast Recovery Area field, do one of the following:
Leave the setting at its default value
Enter a different fast recovery area
Click Browse and select a different fast recovery area.
The fast recovery area can be used to recover data that would otherwise be lost during a failure. This location is also used by Enterprise Manager if you have enabled local management and daily backups on the Database Control Management Options page.
In the Fast Recovery Area Size field, select the units you want from the list and do one of the following:
Leave the setting at its default value.
Enter a different value for Fast Recovery Area Size.
Use the up and down arrows to set a different Fast Recovery Area Size.
In the Recovery Configuration window, you specify a fast recovery area and enable archiving. It is important to configure these features for your database so you can recover your data if a failure occurs.
Click Next.
The Summary window appears.
Review the list the initialization parameters that will be set for the database during the upgrade. Click Back to correct any errors, or click Finish.
|
Note: The database is not be available for general use during the upgrade process that begins when you click Finish. |
A Progress window appears and DBUA begins to perform the upgrade.
You might encounter error messages with Ignore and Abort choices:
Ignore - Ignores the error, skips the current step, and proceeds with the upgrade. The ignored errors are logged and shown later in the summary. After the upgrade is complete, you can fix the problem, restart DBUA, and complete the skipped steps.
Abort - Stops the upgrade process. DBUA prompts you to restore the database if the database backup was performed by DBUA. After the database has been restored, correct the error and restart DBUA to perform the upgrade again. If you do not restore the database, then DBUA leaves the database in its current state so that you can proceed with a manual upgrade.
After the upgrade has completed, the following message is displayed:
Upgrade is complete. Click "OK" to see the results of the upgrade.
Click OK.
The Upgrade Results window appears.
Examine the results of the upgrade. The upgrade results summary describes the original and upgraded databases and changes made to the initialization parameters.
The upgrade results also include an Upgrade Details section that describes the steps performed during the database upgrade. This section provides each step name, the log file for the step, and the status. In some cases, you can click the status to display details about the execution step. The Upgrade Details section also includes the directory where the various log files are stored after the upgrade. You can examine any of these log files to obtain more details about the upgrade process.
|
Note: An HTML version of the Upgrade Results is also saved in the log files directory. |
Click Configure Database Passwords.
The Password Management dialog box appears.
The Password Management dialog box enables you to change the default password for a user after you upgrade the database.
|
Note: To prevent unauthorized use of the database, change all user passwords immediately after you upgrade your database. |
Click the Lock Account? column for a user to lock or unlock an account. A check mark indicates that the account is locked.
Enter a new password for a user in its New Password column.
Confirm the new password by entering it in the Confirm Password column.
Click OK to return to the Upgrade Results window.
Click Restore if you are not satisfied with the upgrade results.
Depending on the method you used to back up your database, the restore operation performs one of the following tasks:
If you used DBUA to back up your database, then clicking Restore copies the original database files and the original database settings from the backup.
If you used your own backup procedure to back up the database, then clicking Restore copies only the original database settings. To restore the database itself, copy the data files from the backup you created using your own backup utilities.
Click Close to quit DBUA if you are satisfied with the upgrade results.
DBUA removes the entry of the upgraded database from the old listener.ora file and restarts the listener.
|
WARNING: If you retain the old Oracle Database software, then never start the upgraded database with it. Only start the database with the executable files in the new Oracle Database installation. Also, before you remove the old Oracle Database environment, make sure you relocate any data files in that environment to the new Oracle Database environment. See Oracle Database Administrator's Guide for information about relocating data files. |
|
See Also:
|
If you want to remove an Oracle software installation, you can use the Deinstallation tool to completely uninstall the software from your computer.
The Deinstallation Tool (deinstall) is available in Oracle home directories after installation as $ORACLE_HOME/deinstall/deinstall. The Deinstallation Tool is also available for download as a separate archive file from the Oracle Technology Network (OTN) site (http://www.oracle.com/technology/software/products/database/index.html).
To remove an Oracle home from your computer:
Execute the Deinstallation tool. The command you enter depends on whether you are executing the tool from an installed Oracle home or executing the tool after downloading it from OTN. Do one of the following:
If you are executing the tool from an installed Oracle home, the following is an example of the commands you would enter:
$ cd /u01/app/oracle $ product/11.2.0/dbhome_1/deinstall/deinstall
If you are executing the tool after downloading and unzipping the archive file from OTN, enter the following command (replacing Oracle_home with the full path name for your Oracle home):
$ deinstall -home Oracle_home
|
Note: Do not shut down the Oracle database or stop any database processes prior to running the Deinstallation tool. |
Enter the specified information at the prompts, or just press Enter to accept the default values.
When prompted, follow the directions to run the root script. You must be the root user to do so.
|
See Also:
|
Oracle By Example (OBE) has a series on the Oracle Database 2 Day DBA guide. This OBE steps you through the tasks in this chapter, and includes annotated screenshots.
To view the Managing Oracle Software OBE, in your browser, enter the following URL:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/2day_dba/managing/managing.htm
This appendix discusses using Oracle Automatic Storage Management (Oracle ASM). Oracle ASM is Oracle's recommended storage management solution that provides an alternative to conventional volume managers, file systems, and raw devices. This chapter includes the following topics:
|
See Also:
|
Oracle Automatic Storage Management (Oracle ASM) is an integrated, high-performance database file system and disk manager. You use Oracle ASM instead of an operating system file system to store your Oracle Database files and, optionally, other files.
Oracle ASM is based on the principle that the database should manage storage instead of requiring an administrator to do it. Oracle ASM eliminates the need for you to manage potentially thousands of database files.
Oracle ASM groups the disks in your storage system into one or more disk groups. You manage a small set of disk groups, and Oracle ASM automates the placement of the database files within those disk groups.
Oracle ASM provides the following benefits:
Striping—Oracle ASM spreads data evenly across all disks in a disk group to optimize performance and utilization. This even distribution of database files eliminates the need for regular monitoring and I/O performance tuning.
For example, if there are six disks in a disk group, then pieces of each Oracle ASM file are written to all six disks. These pieces are known as extents. In this scenario, these pieces come in 1 MB chunks. When a database file is created, it is striped (divided into extents and distributed) across the six disks, and allocated disk space on all six disks increases evenly. When reading the file, file extents are read from all six disks in parallel, greatly increasing performance.
Mirroring—Oracle ASM can increase availability by optionally mirroring any file. Oracle ASM mirrors at the file level, unlike operating system mirroring, which mirrors at the disk level. Mirroring means keeping redundant copies, or mirrored copies, of each extent of the file to help avoid data loss caused by disk failures. The mirrored copy of each file extent is always kept on a different disk from the original copy. If a disk fails, then Oracle ASM can continue to access affected files by accessing mirrored copies on the surviving disks in the disk group.
Oracle ASM supports 2-way mirroring, where each file extent gets one mirrored copy, and 3-way mirroring, where each file extent gets two mirrored copies.
Online storage reconsideration and dynamic rebalancing—Oracle ASM permits you to add or remove disks from your disk storage system while the database is operating. When you add a disk, Oracle ASM automatically redistributes the data so that it is evenly spread across all disks in the disk group, including the new disk. This redistribution is known as rebalancing. It is done in the background and with minimal impact to database performance. When you request to remove a disk, Oracle ASM first rebalances the disk group by evenly relocating all file extents from the disk being removed to the other disks in the disk group.
Managed file creation and deletion—Oracle ASM further reduces administrative tasks by enabling files stored in Oracle ASM disk groups to be Oracle Managed Files. Oracle ASM automatically assigns file names when files are created, and automatically deletes files when they are no longer needed. For information about Oracle Managed Files, see Oracle Database Administrator's Guide.
Oracle recommends that you use Oracle ASM for your database file storage, instead of raw devices or the operating system file system. However, databases can have a mixture of Oracle ASM files and non-Oracle ASM files. Oracle Enterprise Manager includes a wizard that enables you to migrate non-Oracle ASM database files to Oracle ASM.
The Oracle ASM Instance
Oracle ASM is implemented as a special kind of Oracle instance, with its own System Global Area and background processes. The Oracle ASM instance is tightly integrated with the database instance. Every server running one or more database instances that use Oracle ASM for storage has an Oracle ASM instance. In an Oracle Real Application Clusters environment, there is one Oracle ASM instance for each node, and the Oracle ASM instances communicate with each other on a peer-to-peer basis. Only one Oracle ASM instance is required for each node, regardless of the number of database instances on the node.
You administer Oracle ASM with Oracle Enterprise Manager Database Control (Database Control). To administer the Oracle ASM instance and Oracle ASM disk groups, you must connect to the Oracle ASM instance as a user who has been granted the SYSASM system privilege. You can also administer Oracle ASM with Oracle Automatic Storage Management Command Line utility (ASMCMD) and SQL*Plus statements.
When you create the Oracle ASM instance either during installation or using Oracle Automatic Storage Management Configuration Assistant (ASMCA), the SYSASM is granted to the specified Oracle ASM administrator user.
|
See Also:
|
You configure Oracle ASM by creating disk groups that become the default location for files created in the database. The disk group type determines how Oracle ASM mirrors files. When you create a disk group, you indicate whether the disk group is a normal redundancy disk group (2-way mirroring for most files by default), a high redundancy disk group (3-way mirroring), or an external redundancy disk group (no mirroring by Oracle ASM). You use an external redundancy disk group if your storage system does mirroring at the hardware level, or if you have no need for redundant data. The default disk group type is normal redundancy.
A disk group consists of a grouping of disks that are managed as a unit. These disks are referred to as Oracle ASM disks. An Oracle ASM disk can be a disk device, a partition, or a network-attached file.
When an Oracle ASM instance starts, it automatically discovers all available Oracle ASM disks. Discovery is the process of finding all disks that were prepared for Oracle ASM by your system administrator, examining their disk headers, and determining which disks belong to disk groups and which are available for assignment to disk groups. Oracle ASM discovers disks in the paths that are listed in an initialization parameter, or if the parameter is NULL, in an operating system–dependent default path.
Failure groups define Oracle ASM disks that share a common potential failure mechanism. An example of a failure group is a set of small computer system interface (SCSI) disks sharing the same SCSI controller. Failure groups are used to determine which Oracle ASM disks to use for storing redundant copies of data. For example, if 2-way mirroring is specified for a file, then Oracle ASM automatically stores redundant copies of file extents in separate failure groups. Failure groups apply only to normal and high redundancy disk groups. You can define the failure groups in a disk group when you create or alter the disk group, or let Oracle ASM automatically place each disk into its own failure group. For most systems, the default failure groups work well to prevent data loss.
|
See Also:
|
This documentation assumes that Oracle Automatic Storage Management (Oracle ASM) is installed and configured on your single-instance server or on your Oracle Real Application Clusters (Oracle RAC) nodes. For information about installing and initially configuring Oracle ASM, for either a single-instance database or an Oracle RAC database, see Oracle Grid Infrastructure Installation Guide for Linux.
All Oracle Automatic Storage Management (Oracle ASM) administration tasks begin with the Oracle ASM Home page in Database Control. The Oracle ASM Home page displays:
The status of the Oracle ASM instance
A chart that shows the used and free space of each disk group
A list of databases and Oracle ASM Cluster File Systems serviced by the Oracle ASM instance
The procedure for accessing the Oracle ASM Home page differs depending on whether your database is a single-instance database or an Oracle Real Application Clusters database. Details are provided in the following sections:
"Accessing the Oracle ASM Home Page on a Single-Instance System"
"Accessing the Oracle ASM Home Page on an Oracle RAC System"
On a single-instance system, you access the Oracle ASM Home page starting from the Database Home page.
To access the Oracle ASM Home page on a single-instance system:
Go to the Database Home page, logging in as any database user.
Under the General heading, click the link next to the label ASM.
If prompted for Oracle ASM login credentials, then enter the user SYS, provide the SYS password that was set for the Oracle ASM instance upon installation, and connect as SYSASM.
On an Oracle RAC system, you access the Oracle ASM Home page starting from the Cluster Database Home page.
To access the Oracle ASM Home page on an Oracle RAC system:
Log in to Oracle Enterprise Manager on any node that is running the Database Control OC4J instance.
The Database Control OC4J instance is automatically started on the node where DBCA was run to create the cluster database. Depending on your configuration, the Database Control OC4J instance may also be running on other nodes.
On the Cluster Database Home page, under the Instances heading, click the link for the desired Oracle ASM instance.
Using Oracle Enterprise Manager, you can monitor the total capacity of your disk groups, including the amount of unused space and the amount of unused space that can be safely utilized after taking mirroring into account.
To view Oracle Automatic Storage Management (Oracle ASM) disk group usage and free space:
Go to the Oracle ASM Home page.
See "Accessing the Oracle Automatic Storage Management Home Page".
Click Disk Groups to view the Disk Groups subpage.
If the Oracle ASM Login page appears, then log in as the SYS user, connecting as SYSASM. Provide the SYS password that was set when the Oracle ASM instance was created.
The Disk Groups subpage displays all disk groups with their space usage information.
|
Note: The Usable Free column displays the space in gigabytes (GB) that is actually available in the disk group. It takes into account the redundancy level of the disk group, and excludes the space that the disk group reserves for restoring full redundancy for all files in the disk group after a disk failure. |
You may want to create additional Oracle Automatic Storage Management (Oracle ASM) disk groups to do any of the following:
Have disk groups with different redundancy levels (normal, high, or external), depending on availability requirements and storage system capabilities.
Separate different classes of storage (for example, SCSI drives and Serial Advanced Technology Attachment (SATA) drives) into different disk groups. Disks in a disk group should have similar size and performance characteristics.
Store the fast recovery area in a separate disk group from the database.
To create a disk group:
Go to the Oracle ASM Home page.
See "Accessing the Oracle Automatic Storage Management Home Page".
Click the Disk Groups link to display the Disk Groups subpage.
If the Oracle ASM Login page appears, then log in as the SYS user, connecting as SYSASM. Provide the SYS password that was set when the Oracle ASM instance was created.
Click Create.
The Create Disk Group page appears. It displays a list of Oracle ASM disks that are available to be added to a disk group. You can use the Select Member Disks drop-down list to choose whether All Disks or Only Candidate disks are displayed.
Enter the disk group name, and select redundancy type (high, normal, or external).
Select disks as follows:
Select the check box to the left of each disk to include in the new disk group.
To force the inclusion of a disk in the disk group, select the Force Reuse check box for that disk.
|
Caution: The Force Reuse check box causes the disk to be added to the new disk group even if the disk belongs to another disk group and has valid database data. This data will be lost. You must be certain that you are selecting a disk that can legitimately be added to the disk group. |
Optionally enter an Oracle ASM disk name for each selected disk. (Oracle ASM provides a name if you do not.)
Click OK to create the disk group.
|
See Also:
|
When you drop a disk group, you delete the disk group, and all of its files. You cannot drop a disk group if any one of its database files is open. After dropping a disk group, you can add its member disks to other disk groups or use them for other purposes.
One reason to drop a disk group is to change redundancy (normal, high, or external). Because you cannot change the redundancy of a disk group, you must drop the disk group and then re-create it with the proper redundancy. In this case, you must back up or move disk group data before you drop the disk group.
To drop a disk group:
Go to the Oracle ASM Home page.
See "Accessing the Oracle Automatic Storage Management Home Page".
Click the Disk Groups link to display the Disk Groups subpage.
If the Oracle ASM Login page appears, then log in as the SYS user, connecting as SYSASM. Provide the SYS password that was set when the Oracle ASM instance was created.
In the Select column, select the name of the disk group to drop.
Click Delete.
A confirmation page appears.
To delete the disk group even if it still contains files, expand Show Advanced Options and ensure that the Including Contents option is selected.
If the disk group contains files and the Including Contents option is not selected, then you cannot drop the disk group.
On the confirmation page, click Yes.
You add disks to a disk group to increase the total amount of storage space in a disk group. You can add one or multiple disks in a single operation. Oracle ASM then rebalances the disk group so that data is evenly distributed on all disks, including the newly added disks.
You can specify a number to control the power of the rebalance operation. (The range of valid values depends upon the Oracle Database release you are using. See Oracle Automatic Storage Management Administrator's Guide.) The higher the number, the faster the rebalance operation completes. Lower numbers cause rebalancing to take longer, but use fewer processing and I/O resources. This leaves these resources available for the database. The default value of 1 minimizes disruption to the database. A value of 0 prevents the rebalance operation from happening. Manual or automatic rebalancing can then occur at a later time. For example, you may want to postpone rebalancing because you want to wait for a time when there are fewer demands on the database, or because you want to add more disks or drop disks later and want the rebalancing to be done only once for all disk group changes.
To add one or more disks to a disk group:
Go to the Oracle ASM Home page.
See "Accessing the Oracle Automatic Storage Management Home Page".
Click the Disk Groups link to display the Disk Groups subpage.
If the Oracle ASM Login page appears, then log in as the SYS user, connecting as SYSASM. Provide the SYS password that was set when the Oracle ASM instance was created.
Click a link in the Name column to select the disk group to which you want to add disks.
The Disk Group page appears, displaying a list of disks that are in the disk group.
Click Add.
The Add Disks page appears. It displays a list of Oracle ASM disks that are available to be added to the disk group. This includes disks with the header status of CANDIDATE, PROVISIONED, or FORMER.
To display not only disks that are available to be added to a disk group, but all Oracle ASM disks, including disks that belong to a disk group (header status = MEMBER), select All Disks from the Select Member Disks list.
The page is refreshed and now displays the complete list of Oracle ASM disks that were discovered by the Oracle ASM instance.
Optionally change the rebalance power by selecting from the Rebalance Power list.
Select disks as follows:
Select the check box to the left of each disk to add to the disk group.
To force the inclusion of a disk in the disk group, select the Force Usage check box at the right.
|
Caution: The Force Usage check box causes the disk to be added to the disk group even if the disk belongs to another disk group and has valid database data. This data will be lost. You must be certain that you are selecting a disk that can legitimately be added to the disk group. |
Optionally enter an Oracle ASM disk name for each disk. (Oracle ASM provides a name if you do not.)
Click OK to add the selected disks.
|
See Also:
|
When you drop a disk from the disk group, the disk group is rebalanced by moving all of the file extents from the dropped disk to other disks in the disk group. Oracle ASM then releases the disk, and you can then add it to another disk group or use it for other purposes. You can drop one or multiple disks in a single operation. You #can also optionally set rebalance power for the drop operation.
The following is a list of possible reasons for dropping a disk:
A disk is starting to fail, and you must replace it.
You want to upgrade a disk.
You want to reallocate the disk to a different disk group, or reallocate the disk to a different storage system.
|
Note: Dropping disks from a disk group only logically deletes the disks from the disk group. It does not delete the disk contents. However, the contents are lost when you add the disk to a new disk group. |
To drop one or more disks from a disk group:
Go to the Oracle ASM Home page.
See "Accessing the Oracle Automatic Storage Management Home Page".
Click the Disk Groups link to display the Disk Groups subpage.
If the Oracle ASM Login page appears, then log in as the SYS user, connecting as SYSASM. Provide the SYS password that was set when the Oracle ASM instance was created.
Click a link in the Name column to select the disk group from which you want to drop disks.
The Disk Group page appears.
Under the Member Disks heading, in the Select column, select the check boxes for the disks to drop, and then click Remove.
A confirmation page appears.
To change rebalance power, or to set the FORCE option for dropping disks, do the following:
Expand Show Advanced Options.
Optionally select the Force option or select a value for rebalance power in the Rebalance Power list.
|
Note: You may need theFORCE option if Oracle ASM cannot read from or write to the disk. |
Click Yes to drop the disks.
The Disk Group page returns, and displays a state of DROPPING for each disk being dropped.
Refresh the page until the dropped disks no longer appear in the disk group.
|
Caution: You cannot reuse or disconnect the dropped disks until the drop and rebalance operations are complete—that is, until the dropped disks no longer appear in the disk group. |
|
See Also:
|
Oracle recommends that you use Recovery Manager (RMAN) to back up files managed by Oracle ASM. See Chapter 9, "Performing Backup and Recovery" for the information about using RMAN for performing backups.
Oracle By Example (OBE) has a series on the Oracle Database 2 Day DBA guide. This OBE steps you through the tasks in this appendix and includes annotated screenshots.
To view the Oracle Automatic Storage Management OBE, in your browser, enter the following URL:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/2day_dba/asm/asm.htm
Oracle Database 2 Day DBA is a database administration quick start guide that teaches you how to perform day-to-day database administrative tasks. The goal of this book is to help you understand the concepts behind Oracle Database. It teaches you how to perform all common administration tasks needed to keep the database operational, including how to perform basic troubleshooting and performance monitoring activities.
Oracle Database 2 Day DBA is for anyone who wants to perform basic administrative tasks with Oracle Database. Only minimal basic knowledge of or experience with database management is required, and a basic knowledge of computers.
In particular, this guide is for the following groups of Oracle users:
Developers who want to acquire basic database administrator (DBA) skills
Anyone managing database servers
Database administrators managing an Oracle database for a small or medium-sized business
This book is equally useful for enterprise DBAs. It recommends best practices and describes efficient ways of performing administrative tasks with Oracle Enterprise Manager as the primary interface.
For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.
Access to Oracle Support
Oracle customers have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.
For more information, see these Oracle resources:
Oracle Real Application Clusters Installation Guide for Linux and UNIX or other operating system
Oracle Real Application Clusters Administration and Deployment Guide
There are also several other 2 Day + books available for a variety of topics:
Oracle Database 2 Day + Data Replication and Integration Guide
Oracle Database 2 Day + .NET Developer's Guide for Microsoft Windows
Oracle Database 2 Day + Application Express Developer's Guide
Many of the examples in this guide use the sample schemas, which are installed by default when you select the Basic Installation option with an Oracle Database installation. See Oracle Database Sample Schemas for information about how these schemas were created and how you can use them.
To download free release notes, installation documentation, updated Oracle documentation, white papers, or other collateral, visit the Oracle Technology Network (OTN). You must register online before using OTN; registration is free and can be done at
http://www.oracle.com/technetwork/community/join/overview/index.html
If you have a user name and password for OTN, then you can go directly to the documentation section of the OTN Web site at
http://www.oracle.com/technology/documentation/
The following text conventions are used in this document:
| Convention | Meaning |
|---|---|
| boldface | Boldface type indicates graphical user interface elements associated with an action, or terms defined in text or the glossary. |
| italic | Italic type indicates book titles, emphasis, or placeholder variables for which you supply particular values. |
monospace | Monospace type indicates commands within a paragraph, URLs, code in examples, text that appears on the screen, or text that you enter. |
After installing Oracle Database, you have a fully functional database with a client/server network environment that has been minimally configured.
This chapter contains the following sections to help you completely configure your client/server network:
A client is any application that connects to Oracle Database to send or retrieve data. An Oracle Database client application can reside on any computer that has Oracle Database client software installed.
Oracle Net is a software layer that resides on the client computer and on the Oracle Database host computer. It establishes and maintains the connection between the client application and the database over a network, and exchanges messages between them using industry standard protocols.
For a client application and a database to communicate, the client application must be able to identify the database it wants to connect to, and the database must provide an identification. You can use a service name to connect to a database. A service name is a logical representation of a database, which is the way a database is presented to clients. A single database can be presented as multiple services.
Service names can provide location transparency so that the client application does not have to know the server's location. If the database is moved to another location, then you must reconfigure only Oracle Net. No changes are necessary to client applications.
This section contains these topics:
On the database host, the Oracle Net listener (the listener), is a process that listens for client connection requests. It receives incoming client connection requests and manages the traffic of these requests to the database server.
The default listener configuration file is called listener.ora, and it is located in the network/admin subdirectory of the Oracle home directory. For example, if your Oracle home directory is /u01/app/oracle/product/11.2.0/dbhome_1, then the listener.ora file is created by default in the /u01/app/oracle/product/11.2.0/dbhome_1/network/admin directory.
The file contains a protocol address that identifies the database. 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=dbhost.example.com) (PORT=1521)))
This example shows a TCP/IP protocol address that specifies the host computer of the listener and a port number. The listener can listen for connection requests on network interfaces with either IP version 4 (IPv4) or IP version 6 (IPv6) addresses.
The listener.ora file is automatically configured during installation, but you can reconfigure it with Oracle Enterprise Manager Database Control.
Because the configuration parameters have default values, you can start and use a listener without configuring it. This default listener is named LISTENER, supports no service names on startup, and listens on the following TCP/IP protocol address:
(ADDRESS=(PROTOCOL=tcp)(HOST=host_name)(PORT=1521))
An Oracle database registers with the listener within a minute or so of starting up. The service names, or the databases that they represent, to which the listener forwards client requests, can be configured in the listener.ora file. This information can also be dynamically registered with the listener. Dynamic registration of services and databases with the listener is called service registration.
Service registration is performed by the process monitor (PMON) process—an instance background process—of each database instance. Dynamic service registration does not require modification of the listener.ora file.
|
See Also:
|
The following sections describe the elements involved in client connections to the database:
Connect Descriptors
The client uses a connect descriptor to specify the database to which it wants to connect. This connect descriptor contains a protocol and a database service name. A database can have multiple service names defined, so a specific service name must be specified for the connect descriptor. In a preconfigured database, there is only one service name, which defaults to the global database name.
The following example shows a connect descriptor that enables clients to connect to a database with service name mydb.us.example.com:
DESCRIPTION=
(ADDRESS=(PROTOCOL=tcp)(HOST=my-server) PORT=1521))
(CONNECT_DATA=
(SERVICE_NAME=mydb.us.example.com))
Connection Requests
Users initiate a connection request by providing a connect string. A connect string includes a user name and password, and a connect identifier. This connect identifier can be the connect descriptor itself, or a name that resolves to the connect descriptor using mapping information stored in one or more repositories accessed with the naming methods described in "Naming Methods". This name is referred to as a net service name.
Naming Methods
A naming method is a resolution method used by a client application to resolve a connect identifier to a connect descriptor when attempting to connect to a database service.
Oracle Net provides support for the following naming methods:
Easy Connect Naming
The easy connect naming method enables clients to connect to an Oracle database by using only a TCP/IP connect string consisting of a host name and service name. The easy connect naming method requires no configuration. See "Connecting to an Oracle Database from a Client Computer" for an example of easy connect naming.
Local Naming
The local naming method stores connect descriptors, identified by their net service names, in a client configuration file named tnsnames.ora. This file is located in the ORACLE_HOME/network/admin directory. When you create a database using Oracle Database Configuration Assistant (DBCA), local naming is configured automatically. You must then use the Net Configuration Assistant to create connect descriptors and their corresponding net service names.
Directory Naming
Directory naming resolves a database service, net service name, or net service alias to a connect descriptor stored in an LDAP-compliant directory server.
Oracle Database enables you to manage your network configuration with the following tools:
Net Configuration Assistant
During a typical database installation, Net Configuration Assistant (NETCA) automatically configures a listener called LISTENER that has a TCP/IP listening protocol address for the database. If you do a custom installation, then NETCA prompts you to configure a listener name and protocol address of your choice.
Use NETCA for initial network configuration after database installation. Thereafter, you can use Oracle Enterprise Manager and Oracle Net Manager to configure and administer your networks.
Oracle Enterprise Manager
Oracle Enterprise Manager enables you to manage your server-side network configuration with a Listener page. The Listener page displays information such as the current status, the Oracle home directory in which the listener configuration files are located, and the host name.
Oracle Net Manager
Oracle Net Manager provides the same features as Oracle Enterprise Manager with the addition of configuring profiles.
The Oracle Net listener (the listener) runs on your database host and handles incoming client requests. With Oracle Enterprise Manager Database Control (Database Control), you can view the status of the listener, which is set to start automatically whenever your host is restarted. You can also view the listener status at the command line.
To view information about the listener with Database Control:
On the Database Home page, under the heading General, click the Listener link.
The Listener page appears, displaying the following information about the listener:
Current status
Availability over the last 24 hours
Alias
Version
Oracle home for the listener
Net address
Configuration file (listener.ora) location
Start time
Host
(Optional) Status of Oracle Restart
To view information about the listener at the command line:
Open a command window.
Follow the steps listed in "Configuring the Operating System Environment Variables".
Enter the following command:
lsnrctl status
The Oracle listener is set to start automatically whenever the host is restarted. However, when your system encounters unforeseen circumstances, or when you have manually stopped the listener, you can restart it with Database Control or at the command line.
To stop the listener with Database Control:
On the Database Home page, under General, click the Listener link.
The Listener page appears.
Click Stop.
Enter the host credentials, if you did not configure Preferred Credentials, then click Login.
On the Start/Stop Listener page, click OK to perform the specified action or Cancel to quit.
To start the listener with Database Control:
On the Database Home page, under the heading General, click the Listener link.
The Listener page appears.
Click Start.
On the Start/Stop Listener page, click OK.
After a couple of minutes, a confirmation message appears, indicating that the listener has been started.
|
Note: If you have just stopped the listener and are still at the Database Control Listener page, then you will not see a Start button. You must go to the Database Home page, wait a minute or two, and then return to the Listener page. |
To start or stop the listener at the command line:
Open a command window.
Follow the steps listed in "Configuring the Operating System Environment Variables".
Enter either of the following commands, depending on whether you want to start or stop the listener:
lsnrctl start lsnrctl stop
This section describes how to use SQL*Plus and the easy connect naming method to connect to an Oracle database from a client computer. SQL*Plus is typically installed when you install Oracle Database client software. The easy connect naming method provides TCP/IP connectivity to databases without requiring you to configure Oracle Net Services.
You can use the instructions in this section to test your network configuration.
To connect to an Oracle database from a client computer using easy connect naming:
Complete the steps in "Configuring the Operating System Environment Variables".
Do one of the following to start SQL*Plus:
(UNIX, Linux, or Windows systems) Open a command window and enter the following command:
sqlplus
(Windows systems only) Click Start, select Programs (or All Programs), then Oracle - HOME_NAME, then Application Development, and then SQL*Plus.
When prompted, enter the user name followed by an at sign (@) and a connect identifier, where the connect identifier has the following format:
"host[:port][/service_name][:server][/instance_name]"
The place holders used in the connect identifier format represent:
host — the name or IP address of the Oracle database host computer.
Both IPv4 and IPv6 addresses are supported. IPv6 addresses must be enclosed in square brackets. See Oracle Database Net Services Administrator's Guide for information about IPv6 addressing.
port (optional) — the TCP port number on which the Oracle Net listener listens for connections.
If port is excluded, then the standard port number 1521 is assumed.
service_name — a database service name.
If no database service names are defined, then you can use the name of the default service that is created for the database. This service name consists of the global database name, which is made up of the DB_NAME and DB_DOMAIN initialization parameters as follows:
DB_NAME.DB_DOMAIN
If DB_DOMAIN is null, then the standard service name is just DB_NAME.
server — the type of service handler. Acceptable values are dedicated, shared, and pooled. If omitted, then the default type of server is chosen by the listener: shared server if configured, otherwise dedicated server.
instance_name — the instance to which to connect. When you specify only instance name, you connect to the default database service. If there is no default service configured in the listener.ora file, then an error is generated.You can obtain the instance name from the INSTANCE_NAME initialization parameter.
For example, to connect as user NICK to the database service orcl.example.com on the host dbhost.example.com, enter the following at the user name prompt:
nick@"dbhost.example.com/orcl.example.com"
The following examples substitute IPv4 and IPv6 addresses for the host name:
nick@"192.0.2.1/orcl.example.com" nick@"[2001:0DB8:0:0::200C:417A]/orcl.example.com"
When prompted, enter the user password.
|
See Also:
|
Oracle By Example (OBE) has a series on the Oracle Database 2 Day DBA guide. This OBE steps you through the tasks in this chapter and includes annotated screenshots.
To view the Networking OBE, enter the following URL in your browser:
http://www.oracle.com/webfolder/technetwork/tutorials/obe/db/11g/r2/2day_dba/network/network.htm