Commvault is a partner in the Oracle Backup Solutions Program. This service can also be used for migration and replication. The Commvault Oracle service is more of a database data management system than just a backup system. The package includes systems for setting up development and test environments and migrating new products into production. The data manager also archives off static data.
That data archiving service reduces the size of tables, making important live data quicker to restore in the event of a disaster. The archiver also manages the refresh process so that older data can be brought back when needed and searched as though it never left. The Commvault backup can be used for replication or migration and can mediate between incompatible architectural systems.
In addition, the Backup and Recovery service is available for review as a demo system. Quest has several proprietary systems that it was building into its Rapid Recovery service, and there are a few new names to learn when looking into this service.
The first is AppAssure , which is the front-end of the backup and recovery system. It also works on entire systems. It can extract data from any operating system or cloud platform. It also works with Oracle Archive logs. An exciting feature of the recovery process is that it detects access by users to the database, records the searches they perform, and prioritizes the reinstallation of the data in that search if it has not already been restored.
This is a do-it-yourself backup system with specialized routines for backing up Oracle databases and can also be used for backups of other applications. In addition, there is the possibility of using this software for a system-wide backup system. The Bacula service can be set to run on a schedule so that you would get periodic backups. However, this is a complete copy each time, and there is no incremental backup option available.
The Bacula system is available for Solaris and Linux. Get a download of the code and compile it yourself. Acronis Cyber Backup is an intelligent disaster recovery system from a trusted brand. A nice feature of this tool is that it provides extra malware scanning and data protection services that block unauthorized encryption of Oracle files, thus protecting against ransomware.
The Cyber Backup service will include individual backup applications , virtualized systems, entire servers, and specialist equipment such as storage networks. This is a cloud-based system and you pay for the services that you require. So, for example, if you just want to back up Oracle databases, you pay for that, and if you also want to backup your mail server, you pay for that separately.
The Acronis platform operates a local agent on your system, which runs in a VM for security. However, you access the console through a browser because that is hosted on the Acronis servers.
You can choose to save a local copy and a cloud store, and you can use that remote copy to replicate your database elsewhere. Sample the service by accessing a day free trial. Iperius has a menu of plans for its Backup product, but only two of those editions include a backup service for Oracle databases. These are the Advanced and Full plans. Iperius Backup can be used to protect a range of applications, including virtualizations, mail servers, and Microsoft As well as backing up specific applications, Iperius has a system backup service, which can be implemented as disk imaging or an incremental backup service.
In all cases, the Iperius software needs to be installed on the host of the protected service. It is possible to network the service to feed into a central console hosted on Windows Server. Iperius offers cloud storage space as an optional extra, but you can easily attach your cloud account to the backup system. The package includes the Iperius Recovery Environment , which can access damaged operating systems and reassemble broken file pointers.
The datafiles are not in a transaction-consistent state. The online redo log at the moment of the backup must be archived and backed up along with the datafiles to preserve these changes.
In spite of the name, an inconsistent backup is as robust a form of backup as a consistent backup. The great advantage to making inconsistent backups is that you can back up your database while the database is open for updates.
When you restore your datafiles from a consistent backup, you can open the database immediately. When datafiles are restored from an inconsistent backup, you cannot open the database until committed changes recorded in the redo logs are applied to the datafiles, bringing them to a transaction-consistent state.
The process of applying changes from the redo log to the datafiles restored from an inconsistent backup is called media recovery. If you restore the archived redo logs and the datafiles from backups, then you must perform media recovery before you can open the database. Any database transactions in the archived redo logs not already reflected in the datafiles are applied to the datafiles, bringing them to a transaction-consistent state before the database is opened.
Media recovery requires a control file, datafiles typically restored from backup , and online and archived redo logs containing changes since the time the datafiles were backed up. Media recovery is most often used to recover from a 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.
There are two forms of media recovery: complete recovery and point-in-time recovery. In complete recovery, datafiles are restored from backup; all changes from the archived and online redo logs are applied to the datafiles. The database is returned to its state at the time of failure and can be opened with no loss of committed changes. In point-in-time recovery, you return your database to its contents at a target time of your choosing in the past. You start with a backup of datafiles created prior to the target time and a complete set of archived redo log files from the time of that backup through the target time.
During recovery, each change between the backup time and the target time is applied to the datafiles. Point-in-time recovery can return your whole database to its state at any time between the time of your backup and the most recent change in the archived redo logs. All changes after the target time are discarded. Point-in-time recovery is also sometimes called incomplete recovery because you do not recover the complete set of changes to your database. Enterprise Manager provides a convenient interface to both complete and point-in-time recovery in the form of a Recovery Wizard.
However, this book focuses on complete recovery. To simplify the management of backup and recovery related files, Oracle enables you to create a flash recovery area for your database. You must designate the following:. You can then direct backup-related activities, including archiving of redo logs, to store generated files in the flash recovery area.
This process is called rolling back or transaction recovery. Figure illustrates rolling forward and rolling back, the two steps necessary to recover from any type of system failure. Oracle can roll back multiple transactions simultaneously as needed. All transactions systemwide that were active at the time of failure are marked as terminated. Instead of waiting for SMON to roll back terminated transactions, new transactions can recover blocking transactions themselves to get the row locks they need.
Crash recovery is used to recover from a failure either when a single-instance database fails or all instances of an Oracle Real Application Clusters database fail. Instance recovery refers to the case where a surviving instance recovers a failed instance in an Oracle Real Application Clusters database. The goal of crash and instance recovery is to restore the data block changes located in the cache of the terminated instance and to close the redo thread that was left open.
Instance and crash recovery use only online redo log files and current online datafiles. Oracle recovers the redo thread s of the terminated instances together. Crash and instance recovery involve two distinct operations: rolling forward the current, online datafiles by applying both committed and uncommitted transactions contained in online redo records, and then rolling back changes made in uncommitted transactions to their original state.
Have a recovery time governed by the number of terminated instances, amount of redo generated in each terminated redo thread since the last checkpoint, and by user-configurable factors such as the number and size of redo log files, checkpoint frequency, and the parallel recovery setting. At the first database open after the failure of a single-instance database or all instances of an Oracle Real Applications Cluster database crash recovery.
When some but not all instances of an Oracle Real Application Clusters configuration fail instance recovery. The recovery is performed automatically by a surviving instance in the configuration. The important point is that in both crash and instance recovery, Oracle applies the redo automatically: no user intervention is required to supply redo logs.
However, you can set parameters in the database server that can tune the duration of instance and crash recovery performance. Also, you can tune the rolling forward and rolling back phases of instance recovery separately.
Use media recovery when one or more datafiles has been physically damaged. This can happen due to hardware errors or user errors, such as accidentally deleting a file. Complete media recovery is used with individual datafiles, tablespaces, or the entire database. Use incomplete media recovery when the database has been logically damaged. This can happen due to application error or user error, such as accidentally deleting a table or tablespace.
Incomplete media recovery is used only with the whole database, not with individual datafiles or tablespaces. If you do not want to do incomplete media recovery of the entire database, you can do tablespace point-in-time recovery with individual tablespaces.
Use block media recovery when a small number of blocks in one or more files have been physically damaged. Block media recovery is used with individual data blocks, and the remainder of the database remains online and available during the recovery. Flashback Table is a push button solution to restore the contents of a table to a given point in time. An application on top of Flashback Query can achieve this, but with less efficiency. Flashback Database applies to the entire database.
It requires configuration and resources, but it provides a fast alternative to performing incomplete database recovery. Flashback Table uses information in the undo tablespace to restore the table. This provides significant benefits over media recovery in terms of ease of use, availability, and faster restoration. Flashback Database and Flashback Table differ in granularity, performance, and restrictions.
For a primary database, consider using Flashback Database rather than Flashback Table in the following situations:. A user error affected a table or a small set of tables, but the impact of reverting this set of tables is not clear because of the logical relationships between tables. A user error affected a table or a small set of tables, but using Flashback Table would fail because of its DDL restrictions.
Also, because Flashback Database moves the entire database back in time, constraints are not an issue, whereas they are with Flashback Table. Flashback Table cannot be used on a standby database. For example, to create a copy of the table as of a specific time:. For out of place creation of the table, you only get data back.
Constraints, indexes, and so on are not restored. This could take significantly more time and space than Flashback Table. However, Flashback Table only restores rows in blocks that were modified after the specified time, making it more efficient.
In contrast to physical backups, logical backups are exports of schema objects, like tables and stored procedures, into a binary file. Oracle utilities are used to move Oracle schema objects in and out of Oracle. Export, or Data Pump Export, writes data from an Oracle database to binary operating system files.
Import, or Data Pump Import, reads export files and restores the corresponding data into an existing database. Although import and export are designed for moving Oracle data, you can also use them as a supplemental method of protecting data in an Oracle database. You should not use Oracle import and export utilities as the sole method of backing up your data.
Oracle import and export utilities work similarly to CTAS, but they restore constraints, indexes, and so on. They effectively re-create the whole table if an export was performed earlier corresponding to the Flashback time. Use tablespace point-in-time recovery when one or more tablespaces have been logically damaged, and you do not want to do incomplete media recovery of the entire database. Tablespace point-in-time recovery is used with individual tablespaces.
The flash recovery area is an Oracle-managed directory, file system, or Automatic Storage Management disk group that provides a centralized disk location for backup and recovery files. Oracle creates archived logs in the flash recov ery area. RMAN can store its backups in the flash recovery area, and it uses it when restoring files during media recovery.
The flash recovery area also acts as a disk cache for tape. Oracle recovery components interact with the flash recovery area ensuring that the database is completely recoverable using files in flash recovery area. All files necessary to recover the database following a media failure are part of flash recovery area. Oracle lets you define a disk limit, which is the amount of space that Oracle can use in the flash recovery area.
A disk limit lets you use the remaining disk space for other purposes and not to dedicate a complete disk for the flash recovery area. It does not include any overhead that is not known to Oracle. For example, the flash recovery area disk limit does not include the extra size of a file system that is compressed, mirrored, or some other redundancy mechanism.
Oracle and RMAN create files in the flash recovery area until the space used reaches the flash recovery area disk limit. Then, Oracle deletes the minimum set of existing files from the flash recovery area that are obsolete, redundant copies, or backed up to tertiary storage.
The bigger the flash recovery area, the more useful it becomes. The recommended disk limit is the sum of the database size, the size of incremental backups, and the size of all archive logs that have not been copied to tape.
If the flash recovery area is big enough to keep a copy of the tablespaces, then those tablespaces do not need to access tertiary storage. The minimum size of the flash recovery area should be at least large enough to contain archive logs that have not been copied to tape. For example, if an ASM disk group of size GB is used with normal redundancy for the flash recovery area, then the flash recovery area disk limit must be set to 50 GB.
Oracle Database Backup and Recovery Advanced User's Guide for the rules that define the priority of file deletion, as well as other information about the flash recovery area. Oracle Database Administrator's Guide for information about how to set up and administer the flash recovery area.
Introduction to Backup A backup is a copy of data. Consistent and Inconsistent Backups A consistent backup is one in which the files being backed up contain all changes up to the same system change number SCN.
Overview of Inconsistent Backups An inconsistent backup is a backup in which the files being backed up do not contain all the changes made at all the SCNs.
If such a backup is used to restore the database, then data corruption might result. Archiving Unarchived Redo Log Files After an online backup or inconsistent closed backup, always ensure that you have the redo necessary to recover the backup by archiving the unarchived redo logs. Backing Up the Archived Logs and the Control File After open or inconsistent closed backups, Oracle recommends backing up all archived logs produced during the backup, and then backing up the control file after the backup completes.
Whole Database Backups A whole database backup is a backup of every datafile in the database, plus the control file. Tablespace Backups A tablespace backup is a backup of the datafiles that constitute the tablespace. Datafile Backups A datafile backup is a backup of a single datafile.
The datafiles are read only or offline-normal. Note : Unlike operating system copies, RMAN validates the blocks in the file and records the copy in the repository.
RMAN with Online Backups Because the database continues writing to the file during an online backup, there is the possibility of backing up inconsistent data within a block. Control File Backups Backing up the control file is a crucial aspect of backup and recovery. Archived Redo Log Backups Archived redo logs are essential for recovering an inconsistent backup. Introduction to Recovery To restore a physical backup of a datafile or control file is to reconstruct it and make it available to the Oracle database server.
Overview of Media Recovery The type of recovery that takes a backup and applies redo is called media recovery. This section contains the following topics: Complete Recovery Incomplete Recovery Datafile Media Recovery Block Media Recovery Complete Recovery Complete recovery involves using redo data or incremental backups combined with a backup of a database, tablespace, or datafile to update it to the most current point in time.
If you are performing complete recovery on the whole database, then you must: Mount the database Ensure that all datafiles you want to recover are online Restore a backup of the whole database or the files you want to recover Apply online or archived redo logs, or a combination of the two If you are performing complete recovery on a tablespace or datafile, then you must: Take the tablespace or datafile to be recovered offline if the database is open Restore a backup of the datafiles you want to recover Apply online or archived redo logs, or a combination of the two.
Incomplete Recovery Incomplete recovery, or point-in-time recovery, uses a backup to produce a noncurrent version of the database. You usually perform incomplete recovery of the whole database in the following situations: Media failure destroys some or all of the online redo logs. A user error causes data loss, for example, a user inadvertently drops a table. You cannot perform complete recovery because an archived redo log is missing.
You lose your current control file and must use a backup control file to open the database. Note: Flashback Database is another way to perform incomplete recovery. Tablespace Point-in-Time Recovery The tablespace point-in-time recovery TSPITR feature lets you recover one or more tablespaces to a point in time that is different from the rest of the database. TSPITR is most useful when you want to: Recover from an erroneous drop or truncate table operation Recover a table that has become logically corrupted Recover from an incorrect batch job or other DML statement that has affected only a subset of the database Recover one independent schema to a point different from the rest of a physical database in cases where there are multiple independent schemas in separate tablespaces of one physical database Recover a tablespace on a very large database VLDB rather than restore the whole database from a backup and perform a complete database roll-forward TSPITR has the following limitations: You cannot use it on the SYSTEM tablespace, an UNDO tablespace, or any tablespace that contains rollback segments.
Incomplete Media Recovery Options Because you are not completely recovering the database to the most current time, you must tell Oracle when to terminate recovery. Type of Recovery Function Time-based recovery Recovers the data up to a specified point in time. Change-based recovery Recovers until the specified SCN.
Log sequence recovery Recovers until the specified log sequence number only available when using Recovery Manager. Datafile Media Recovery Datafile media recovery is used to recover from a lost or damaged current datafile or control file. Media recovery has the following characteristics: Applies changes to restored backups of damaged datafiles. Can use archived logs as well as online logs. Requires explicit invocation by a user. The following scenarios necessitate media recovery: You restore a backup of a datafile.
You restore a backup control file even if all datafiles are current. Block Media Recovery Block media recovery is a technique for restoring and recovering individual data blocks while all database files remain online and available.
See Also: Oracle Database Backup and Recovery Reference for information on how to catalog user-managed datafile and archived log backups and to perform block media recovery. RMAN automates the procedure for recovering and restoring your backups and copies. You should follow these basic steps: After identifying which files are damaged, place the database in the appropriate state for restore and recovery. Restore any necessary archived redo log files.
0コメント