Oracle Database 11g: Administration Workshop I. Volume I • Student Guide. DGC Edition September D Oracle University and En- Sof. Jobs 17 - 37 Volume I • Student Guide. DGC20 Edition September D THESE eKIT MATERIALS ARE FOR YOUR USE IN THIS. Oracle Database Administrator's Guide, 11g Release 2 (). E . Part I Basic Database Administration. 1 Getting Started with Database Administration.
|Language:||English, Spanish, German|
|Genre:||Fiction & Literature|
|Distribution:||Free* [*Registration Required]|
The Oracle Database 11g: Administration I Exam Study Guide is designed to The exam audience is represented by Oracle Database 11g administrators, that. Oracle DBA Concise Handbook. Oracle DBA .. Word format (PDF format is also available). So, you can From 11g, Oracle can manage SGA and PGA completely automatically. - 7 -. SYSTEM CREATE TABLE student () PARTITION BY. Oracle database 11g administration workshop ii student guide pdf. I only dislike the noise between songs. I ve disabled it for IE and also UC Browser, but both.
Grid computing can achieve the same very high level of reliability as mainframe computing because all components are clustered. But unlike mainframes and large UNIX symmetric multiprocessing SMP servers, a grid can be built with open system technologies, such as Intel processors and the Linux operating system, at a very low cost.
As disks are added or dropped, ASM redistributes the data automatically. There is no need for a logical volume manager to manage the file system. Data availability increases with optional mirroring, and you can add or drop disks online. See the lesson titled Managing Database Storage Structures. Oracles Real Application Clusters runs and scales all application workloads on a cluster of servers and offers the following features: Integrated clusterware: This includes functionality for cluster connectivity, messaging and locking, cluster control, and recovery.
It is available on all platforms that are supported by Oracle Database 10g. Automatic workload management: Rules can be defined to automatically allocate processing resources to each service both during normal operations and in response to failures. The role includes the following system privileges: After you have created the user. Set the default tablespace for this user to the tablespace you created for the recovery catalog.
As with any database. Creating the Recovery Catalog After creating the catalog owner. Managing Target Database Records in the Recovery Catalog Although most information is automatically propagated from the control file to the recovery catalog.
RMAN performs the following actions: To register your target database. Invoke RMAN and connect to the recovery catalog database and to the target database as shown in the following example: Registering a Database in the Recovery Catalog After creating the recovery catalog. Ensure that the target database is mounted or open. Specify that the target database is to use the recovery catalog chosen in the list.
The EM method of registration also causes EM to use the recovery catalog for backup and recovery—related operations. If you use RMAN to register the database. Click Add Recovery Catalog to specify the host. When you click OK. To register a database with a recovery catalog. In Enterprise Manager: Running EM on the target database. After you have defined the recovery catalog database. From the EM Database home page.
Add the recovery catalog to the configuration. The recovery catalog records for that database are then based on the contents of the control file at the time of re-registration. Unregistering a Target Database from the Recovery Catalog When you unregister a database from the recovery catalog. If you have used Enterprise Manager Database Control to register your database. You can reregister the database. Use this when you no longer want the target database to be defined in the recovery catalog.
Examples of cataloging a control file. You can catalog all files in the currently enabled Flash Recovery Area as follows: You cannot use wildcards. This enables RMAN to use the files during a restore operation. Provide a prefix that indicates the directory and possibly a file prefix to look for.
If backups have aged out of the control file. Cataloging Additional Backup Files If you have additional control file copies. Cataloging Additional Backup Files continued All types of backup files that are found in the specified directory and subdirectories are cataloged. The following accomplishes that: The following command catalogs all of them: Recovery Catalog Resynchronization: There are two types of resynchronization: The database schema includes names and locations of data files.
RMAN compares the control file to the recovery catalog and updates the recovery catalog with any metadata concerning backups. For a full synchronization. RMAN first creates a control file snapshot. It compares and updates all the data that a partial resynchronization does. It uses the snapshot to make the comparison to the recovery catalog. For partial resynchronization.
Manually Resynchronizing the Recovery Catalog Perform a manual resynchronization of the recovery catalog in the following situations: Manually resynchronize the recovery catalog in the following situations: A local stored script is associated with the target database to which RMAN is connected when the script is created.
Unlike command files that are available only on the system on which they are stored. Stored scripts are: Stored scripts can be defined as global or local. A global stored script can be executed against any database registered in the recovery catalog. If an RMAN command in the script fails. When you execute the script.
RMAN creates the script if it does not exist. This command displays the names of all stored scripts. To delete a stored script from the recovery catalog. Any time you make a backup in the target database. Configure control file autobackup so that the control file is backed up every time a backup is made of the recovery catalog. Oracle recommends using RMAN to back it up and.
Below is a summary of how to configure the backup and recovery environment for your recovery catalog: This protects the record of the latest backup.
A recovery catalog is effective only if it is separated from the data that it is designed to protect. Never store a recovery catalog containing the RMAN repository for a database in the same database as the target database or on the same disks as the target database. Note that any metadata from control file records that aged out of the control file is lost.
To partially re-create the contents of a lost recovery catalog.. Use this command to recatalog any available backups. You can use the following commands to partially repopulate the contents of the recovery catalog: Use this command to update the recovery catalog with any RMAN repository information from the control file of the target database or a control file copy. The import operation creates the catalog in the second database. Use the corresponding Import utility to import the catalog data into the schema created in step 2.
You can also create an export of the recovery catalog to serve as a logical backup. Perform the following steps to export a recovery catalog from one database and import the catalog into a second database: Create a recovery catalog user on the database you are exporting to and grant the user necessary privileges. The recovery catalog can be backed up and moved to another database as a transportable tablespace by using Export and Import or Data Pump.
Use the Export and Import utilities or the Data Pump utilities to: Use one of the Oracle Export utilities to export the catalog data from the database.
Exporting and Importing the Recovery Catalog You can use Export and Import to move the recovery catalog from one database to another. You do not have to be connected to the target database. To upgrade the recovery catalog to the version required by the RMAN client. To drop the recovery catalog schema. If you no longer want to maintain a recovery catalog. Dropping the catalog deletes the recovery catalog record of backups for all target databases registered in the catalog. The catalog database must be open.
You receive an error if the recovery catalog is already at a version greater than that needed by the RMAN executable. RMAN permits the command to be run if the recovery catalog is current. The version of the source recovery catalog schema must be equal to the current version of the RMAN executable. Importing metadata for two registered databases: Importing metadata for all registered databases: Connecting to the destination recovery catalog: RMAN merges metadata for all database IDs from the source catalog schema into the destination catalog schema.
If needed. Importing metadata from multiple catalogs: RMAN issues an error if the database whose metadata is merged is already registered in the recovery catalog schema.
When not specified. You can specify the list of database IDs whose metadata should be imported from the source catalog schema. If you created catalog schemas of different versions to store metadata for multiple target databases. All imported target databases are unregistered from their source catalogs except for the databases registered in the cat92 schema. RMAN renames the stored script of the source catalog schema. If the database name is ambiguous. Before you import catalogs of earlier versions.
Import Examples continued 1. RMAN issues an error. By default. This is the first step in all examples given in the slide. There is never a state of partial import.
RMAN imports metadata for all database IDs registered in these catalogs into the cat schema in the destdb database. You can specify the list of database names whose metadata should be imported. In this example. The srcdb database contains three different recovery catalogs. If a target database is registered in both schemas. You want RMAN to import all registered databases and unregister them in the source catalog.
RMAN must be connected to the destination recovery catalog—for example.
The cat92 user owns an RMAN catalog in the srcdb database. As the virtual catalog owner. As the catalog owner. The virtual catalog owner can then connect to the catalog for a particular target or register a target database. After this configuration. After the VPC is configured. The catalog owner creates the base catalog. Create a virtual private catalog.
If the target database is Oracle Database 10g Release 2 or earlier using a compatible client. Connect to the catalog using the VPC owner login. The virtual catalog owner can see only those databases that privileges have been granted for. Use the virtual catalog: Register a new database in the catalog: For most RMAN operations. Create a virtual catalog for 11g clients: If desired. Managing recovery catalogs: Protect the recovery catalog by including it in your backup and recovery strategy.
Register your target databases in the recovery catalog. Recovery Catalogs Summary The basic workflow of managing recovery catalogs is not new. This step enables RMAN to store metadata for the target databases in the recovery catalog. Protect the recovery catalog.
You can use a recovery catalog in an environment in which you use or have used different versions of the database. As a result. You can use a stored script as an alternative to a command file for managing frequently used sequences of RMAN commands.
The recommended practice is to register all your target databases in a single recovery catalog. The owner of a centralized recovery catalog. A global stored script can be run against any database registered in the recovery catalog. The resynchronization of the recovery catalog ensures that the metadata that RMAN obtains from the control files is current.
The script is stored in the recovery catalog rather than on the file system. All metadata is stored in the base catalog schema. The catalog includes the following types of metadata: You can merge one recovery catalog or metadata for specific databases in the catalog into another recovery catalog for ease of management.
Each restricted user has full read-write access to his or her own metadata. The recovery catalog obtains crucial RMAN metadata from the control file of each registered target database.
Select all statements that are true about the Oracle recovery catalog: Oracle recommends that you use the recovery catalog for all databases without exception. You must use the EM method of registration in order to use the recovery catalog for backup and recovery—related operations within EM.
The recovery catalog allows you to store a longer history of backups than what is possible with a control file—based repository. Administration Workshop II 4. You can save persistent configuration information such as channel parameters, parallelism, and the default device type in the RMAN repository. These configuration settings are always stored in the control file and in the recovery catalog database if it exists. These settings have default values, which allow you to use RMAN immediately.
However, as you develop a more advanced backup and recovery strategy, you may have to change these settings to implement that strategy. These settings are in effect for any RMAN session until the configuration is cleared or changed.
EM Note: The backup settings provide the default settings for all backups taken. When creating a backup, some of these settings can be overridden for that specific backup. To examine the persistent RMAN settings for a database: To easily recover from the loss of all control file copies, you should configure RMAN to take automatic backups of the control file. The automatic backup of the control file occurs independently of any backup of the current control file explicitly requested as part of your backup command.
Otherwise, if you lose your control file, your database may be unrecoverable.
To configure control file autobackup, modify the backup policy for your database by using Enterprise Manager or use the following RMAN command: By default, control file autobackups are disabled. If you enable control file autobackups, then RMAN automatically backs up the control file and the current server parameter file if used to start up the database under the following circumstances: Control file autobackups are stored in the Flash Recovery Area, unless otherwise specified.
With a control file autobackup, RMAN can recover the database even if the current control file, recovery catalog, and server parameter file are inaccessible.
Because the path used to store the autobackup follows a well-known format, RMAN can search for and restore the server parameter file or control file from that autobackup. For example:. Managing Persistent Settings Parallelism is the number of streams of data that can be used to read from and write to the device. This effectively causes that number of channels to be allocated when the device is used by RMAN.
For example, if a media manager has two tape drives available, then parallelism 2 would allow both tape drives to be used simultaneously for BACKUP commands using that media manager. Parallelism for the disk device type is also useful, when you want to spread out a backup over multiple disks.
If SHOW ALL is executed when connected to a target database, only node-specific configurations and database configurations are displayed. A media manager is a utility that loads, labels, and unloads sequential media such as tape drives for the purpose of backing up, restoring, and recovering data.
The Oracle database server calls Media Management Library MML software routines to back up and restore data files to and from media that is controlled by the media manager. Note that the Oracle database server does not need to connect to the MML software when it backs up to disk. Software that is compliant with the MML interface enables an Oracle database session to back up data to a media manager and request the media manager to restore backups.
Check with your media vendor to determine whether it is a member of Oracle BSP. When Recovery Manager executes this command, it sends the backup request to the Oracle database session performing the backup. The Oracle database session identifies the output channel as a media management device and requests the media manager to load a tape and write the output. The media manager labels and keeps track of the tape and the names of the files on each tape.
The media manager also handles restore operations. When you restore a file, the following steps occur: The Oracle database server requests the restoration of a particular file. The media manager identifies the tape containing the file and reads the tape. The media manager passes the information back to the Oracle database session. The Oracle database server writes the file to disk. Using a Media Manager continued Depending on the product that you are installing, perform the following basic steps: Install and configure the media management software on the target host or production network.
No RMAN integration is required at this stage.
Ensure that you can make non-RMAN backups of operating system files on the target database host. This step makes it easier to troubleshoot problems at a later time. Refer to your media management documentation to learn how to back up files to the media manager. Obtain and install the third-party media management module for integration with the Oracle database. This module must contain the library loaded by the Oracle database server when accessing the media manager. Backup and Restore Operations Using a Media Manager The following Recovery Manager script performs a data file backup to a tape drive controlled by a media manager:.
Backups can be written to: Fast Recovery Area: Disk area set aside for backup and recovery and flashback database purposes — Define the location and the size.
Specifying a disk directory or the Fast Recovery Area means that backups go to hard-disk media. Typically, backups are regularly moved offline to tape via the media management interface in order to maintain disk space availability. Any disk directory can be specified as the destination of a backup provided that it already exists. A media management library can be used to copy files to tape devices, or to carry out proxy copies.
A proxy copy is where the MML is requested to make a copy of a file to a disk or tape device. The MML must be able to provide the proxy copy service for this to work.
If you set up a Fast Recovery Area, many backup and recovery tasks are simplified for you. The Oracle database automatically names files for you, and deletes obsolete files when there is space pressure. To specify that backups are to be written to disk, use the first command in the slide. Subsequently, when backups are made, if the FORMAT keyword is used that specifies a disk directory location for the backup , then the backup is written there. If there is a Fast Recovery Area configured, then it goes there; otherwise, backups are written to a platform-specific default location.
To specify that a tape device is to be used, use the second command in the slide. Configuring and Allocating Channels Choose from the following options for configuring channels and executing backups: To create a duplexed backup set, use: For sbt channels, if you use a media manager that supports Version 2 of the SBT API, then the media manager automatically puts each copy onto a separate medium for example, a separate tape.
Note that it is not possible to duplex backup sets to the Fast Recovery Area, and that duplexing applies only to backup sets, not image copies. Duplexed backup sets are typically used for tape backups. You must have automatic channels configured. It creates a single copy to disk. Two copies of the backup are made to two different tapes.
Configure the number of copies on the desired device type for data files and archived redo log files.
Only one copy is made on disk.. If RMAN determines that a file is identical and it has already been backed up. RMAN performs further checking to determine whether to skip the file. Backup Optimization If you enable backup optimization. Configuring Backup Optimization continued To override backup optimization and back up all files whether or not they have changed. You can disable backup optimization on a persistent basis using Enterprise Manager or by issuing the following command: RMAN is able to skip some blocks.
Unallocated blocks may be skipped. They are those that have not been allocated. The following blocks may be skipped during certain types of backup operations: These are blocks that have been allocated but no longer belong to a segment. The available compression algorithms are HIGH.
If you specify it for a specific backup device. This optimization is automatically enabled. The benefit is reduced overall backup time and storage by not backing up undo that applies to committed transactions. Compressing Backups Undo data that is not needed for transaction recovery for example. You do not have to perform any additional steps when restoring a compressed backup. While unused block compression decreases the number of blocks that are written to the backup and the backup time.
So both creating and restoring a compressed backup will. When choosing an algorithm. RMAN can perform binary compression on any backup set that is generated.
Best suited to address backup constraint: It corresponds to the ZLIB compression. It corresponds to the GZIP compression. This corresponds to BZIP2 10g style compression. This level provides a good balance of CPU usage and compression ratio. Choosing a compression level based on your own environment. Because the performance of the various compression levels depends on the nature of the data in the database. The following level or compression ratios are available: This level is the fastest.
To decide which level is best for you. This level provides the best compression ratio. Oracle Corporation cannot document universally applicable performance statistics.
It corresponds to the LZO compression. It is highly recommended that you run tests with the different compression levels on the data in your environment. Best suited to address backup: You must know the password that was used for the backup in order to restore. With a wallet default Password encryption: With a password no wallet Dual mode encryption: This method of encryption relies on a password. Encrypting backups is covered in detail in the Oracle Database 11g: Security course.
There is no need to configure a wallet. This type of encryption is useful if you usually restore your backups to the local site. In order to restore. Both transparent and password encryption are used. Encrypting Backups You can encrypt backups in one of three ways: This method uses a wallet. Connected only to the recovery catalog.
Logged in to the target database instance.
Connected only to the target. How can you examine the persistent RMAN settings for a database? Select all true answers: Persistent RMAN settings can only be used for one-time backups. Select the true statements about RMAN backup functionality: Parallelism is the number of possible streams of data to and from a backup device.
Configuring Backup Specifications Practice Tip: Because the output of the RMAN commands can be quite long. Configuring Backup Specifications. Administration Workshop II 5.
The FORMAT parameter specifies a pattern to use in creating a file name for the backup pieces created by this command. A backup set is a collection of files called backup pieces. RMAN computes a checksum for each block backed up.
An image copy has the following characteristics: To speed up the process of copying.
When the backup is restored. When large files are being considered. Creating Image Copies An image copy is a clone of a single data file. You must use the level 0 option if the copy will be used in conjunction with an incremental backup set. Creating a Whole Database Backup A whole database backup can be either backup sets or image copies of the entire set of data files and must include the control file.
In that case. This is useful especially if you are not using a Fast Recovery Area. Using Recovery Manager RMAN to make an image copy of all the database files simply requires mounting or opening the database. You can also create a backup either a backup set or image copies of previous image copies of all data files and control files in the database by using the following command: That causes RMAN to remove the archivelog files after backing them up. For a full image copy. A full data file backup is a backup that includes every used data block in the file.
A level 0 incremental backup is equivalent to a full backup that has been marked as level 0. RMAN copies all blocks into the backup set or image copy. The only difference is that the level 0 backup as well as an image copy can be used as the base for a level 1 backup. A differential level 1 incremental backup contains only blocks modified since the last incremental backup. Incremental Backups An incremental backup is either a level 0 backup.
A level 0 incremental backup is physically identical to a full backup. A full backup cannot be part of an incremental backup strategy. A cumulative level 1 incremental backup contains only blocks modified since the last level 0 incremental backup.
A full backup has no effect on subsequent incremental backups. Unused block compression causes never-written blocks to be skipped when backing up data files to backup sets.
Note also that recovery is limited to the time of the last backup. Fast Incremental Backup The goal of an incremental backup is to back up only those data blocks that have changed since a previous backup. This makes the incremental backup faster. The maintenance of the tracking file is fully automatic and does not require your intervention. The Oracle database does not record block change information by default. The size of the block change tracking file is proportional to the: RMAN reads only those blocks referenced to locate the changed blocks since the last backup.
Block change tracking writes to a file the physical address of each block that is changed. It also makes recovery faster because fewer blocks need to be restored. RMAN can look at the block change tracking file.
Implemented by block change tracking. You can use RMAN to create incremental backups of data files. When making an incremental backup. You can perform fast incremental backup by enabling block change tracking. When it is time to perform the incremental backup. That makes the backup smaller because only changed blocks are backed up. For this reason. If the change tracking file is stored in the database area with your database files.
You can use the following syntax to change the location of the block change tracking file: You can. RMAN does not support backup and recovery of the block change tracking file. Oracle has created the grid computing infrastructure software that balances all types of workloads across servers and enables all those servers to be managed as one complete system. Grid computing can achieve the same very high level of reliability as mainframe computing because all components are clustered.
But unlike mainframes and large UNIX symmetric multiprocessing SMP servers, a grid can be built with open system technologies, such as Intel processors and the Linux operating system, at a very low cost.
As disks are added or dropped, ASM redistributes the data automatically. There is no need for a logical volume manager to manage the file system. Data availability increases with optional mirroring, and you can add or drop disks online. See the lesson titled Managing Database Storage Structures.
Oracles Real Application Clusters runs and scales all application workloads on a cluster of servers and offers the following features: Integrated clusterware: This includes functionality for cluster connectivity, messaging and locking, cluster control, and recovery. It is available on all platforms that are supported by Oracle Database 10g.