This document discusses user-managed database backup and recovery, including:
- The difference between user-managed and server-managed backup which uses OS commands versus RMAN.
- How to perform a complete database recovery by restoring files and archive logs and applying redo logs.
- How to perform incomplete recovery to recover to a past time or SCN by restoring files and applying redo logs until a specified point.
Duplicating a database creates an identical copy of a database that can be used for testing or recovery purposes. There are multiple techniques for duplicating a database using RMAN, including duplicating from an active database, from RMAN backups, with or without connections to the target instance, recovery catalog, or using backups alone. The key steps are preparing the auxiliary instance, ensuring backups and redo logs are available, allocating auxiliary channels, and using the RMAN DUPLICATE command to restore files and recover the database.
Flashback Database allows rewinding a database to undo data corruptions or errors. It works by using redo logs and block images to restore the database to a previous state. Configuring Flashback Database requires enabling it, setting a retention target, and having the database in ARCHIVELOG mode. Operations include flashing back to a time, SCN, or restore point. Monitoring involves checking the flashback window and log sizes.
This document discusses using Oracle's Recovery Manager (RMAN) to perform various database recovery tasks, including recovering from the loss of data files, using incremental backups to reduce recovery time, switching to image copies for fast recovery, restoring a database to a new host, and performing disaster recovery. It provides examples of using RMAN commands like RESTORE, RECOVER, SWITCH, and SET NEWNAME to restore and recover database files from backups.
This document discusses Oracle's flashback technologies including Total Recall and the recycle bin. Total Recall allows tracking of historical database changes at the table level and querying past data. The recycle bin stores dropped objects and allows restoring them. The document covers setting up Total Recall, accessing historical data, managing space usage in the recycle bin, and querying the recycle bin.
This document discusses configuring a database for recoverability. It covers placing a database in ARCHIVELOG mode, configuring multiple archive log destinations, configuring the Fast Recovery Area (FRA), and specifying retention policies. The key benefits of using the FRA are that it simplifies backup management and automatically manages disk space for recovery files.
This document discusses how to configure Oracle database backup settings using Recovery Manager (RMAN). It covers setting persistent RMAN configuration settings, enabling automatic control file backups, configuring backup destinations and channels, optimizing backups, and creating compressed or encrypted backups. Key topics include using the CONFIGURE command to set backup retention policies, backup copy settings, and backup optimization parameters, as well as allocating channels and specifying backup device types and locations.
Tablespace point-in-time recovery (TSPITR) allows recovery of one or more tablespaces to an earlier point in time without affecting other tablespaces. It performs restore and recovery of data files for the recovery set and auxiliary set to the target time, then exports and imports metadata to make the recovered tablespaces available. TSPITR is useful for undoing DML changes or recovering from logical corruption in a subset of the database, and can be fully automated using RMAN or performed with a custom auxiliary instance.
This document provides an overview of Oracle database concepts and tools. It describes the core components of an Oracle database including the database, server processes, memory structures, and client/server architecture. It also outlines the tools used to configure an Oracle database such as the Oracle Universal Installer, Database Configuration Assistant, and command line utilities. Automatic Storage Management (ASM) is discussed as the preferred storage management solution.
Duplicating a database creates an identical copy of a database that can be used for testing or recovery purposes. There are multiple techniques for duplicating a database using RMAN, including duplicating from an active database, from RMAN backups, with or without connections to the target instance, recovery catalog, or using backups alone. The key steps are preparing the auxiliary instance, ensuring backups and redo logs are available, allocating auxiliary channels, and using the RMAN DUPLICATE command to restore files and recover the database.
Flashback Database allows rewinding a database to undo data corruptions or errors. It works by using redo logs and block images to restore the database to a previous state. Configuring Flashback Database requires enabling it, setting a retention target, and having the database in ARCHIVELOG mode. Operations include flashing back to a time, SCN, or restore point. Monitoring involves checking the flashback window and log sizes.
This document discusses using Oracle's Recovery Manager (RMAN) to perform various database recovery tasks, including recovering from the loss of data files, using incremental backups to reduce recovery time, switching to image copies for fast recovery, restoring a database to a new host, and performing disaster recovery. It provides examples of using RMAN commands like RESTORE, RECOVER, SWITCH, and SET NEWNAME to restore and recover database files from backups.
This document discusses Oracle's flashback technologies including Total Recall and the recycle bin. Total Recall allows tracking of historical database changes at the table level and querying past data. The recycle bin stores dropped objects and allows restoring them. The document covers setting up Total Recall, accessing historical data, managing space usage in the recycle bin, and querying the recycle bin.
This document discusses configuring a database for recoverability. It covers placing a database in ARCHIVELOG mode, configuring multiple archive log destinations, configuring the Fast Recovery Area (FRA), and specifying retention policies. The key benefits of using the FRA are that it simplifies backup management and automatically manages disk space for recovery files.
This document discusses how to configure Oracle database backup settings using Recovery Manager (RMAN). It covers setting persistent RMAN configuration settings, enabling automatic control file backups, configuring backup destinations and channels, optimizing backups, and creating compressed or encrypted backups. Key topics include using the CONFIGURE command to set backup retention policies, backup copy settings, and backup optimization parameters, as well as allocating channels and specifying backup device types and locations.
Tablespace point-in-time recovery (TSPITR) allows recovery of one or more tablespaces to an earlier point in time without affecting other tablespaces. It performs restore and recovery of data files for the recovery set and auxiliary set to the target time, then exports and imports metadata to make the recovered tablespaces available. TSPITR is useful for undoing DML changes or recovering from logical corruption in a subset of the database, and can be fully automated using RMAN or performed with a custom auxiliary instance.
This document provides an overview of Oracle database concepts and tools. It describes the core components of an Oracle database including the database, server processes, memory structures, and client/server architecture. It also outlines the tools used to configure an Oracle database such as the Oracle Universal Installer, Database Configuration Assistant, and command line utilities. Automatic Storage Management (ASM) is discussed as the preferred storage management solution.
This document discusses managing space for databases, including:
- Using 4KB sector disks and specifying disk sector sizes when creating databases, data files, and redo log files.
- Transporting tablespaces and databases between platforms using RMAN and Data Pump utilities.
- The process involves making tablespaces read-only, converting data files to the target platform format, importing metadata, and making tablespaces read/write on the target system.
This document provides an overview of how to create backups with RMAN (Recovery Manager) in Oracle. It discusses creating image file backups, whole database backups, full database backups, enabling fast incremental backups, duplex backup sets, backing up backup sets, multisection backups, archival backups, and reporting on and maintaining backups. The objectives are to learn how to perform various backup tasks with RMAN and manage those backups.
The document discusses how to configure and use the Oracle Database Resource Manager. It describes how to create resource plans and consumer groups, specify directives to allocate resources, map consumer groups to plans, activate a resource plan, and monitor resource usage. The Resource Manager allows managing resources like CPU, parallelism, sessions, and timeouts across different workload groups.
This document discusses diagnosing database issues and corruption. It covers the Data Recovery Advisor, which can detect, analyze, and repair failures. It also covers handling block corruption, setting up the Automatic Diagnostic Repository (ADR) to store diagnostic data, and using the Health Monitor to perform proactive database checks. Key topics include listing and advising on failures using RMAN, performing block media recovery, viewing ADR data with ADRCI, and running manual and automatic Health Monitor checks.
This document discusses monitoring and tuning RMAN backup and restore performance. It describes how to configure RMAN for asynchronous I/O and multiplexing, monitor job progress, identify bottlenecks, and balance backup speed versus recovery speed. Specific parameters like MAXPIECESIZE, FILESPERSET, and MAXOPENFILES are examined for their effect on performance.
This document discusses database performance monitoring and tuning. It covers monitoring sessions and services, database replay for testing, and collecting optimizer statistics. The key activities for performance management are planning, instance tuning, and SQL tuning. Performance is monitored using views for sessions, services, wait events, and statistics. Tuning involves identifying and addressing the greatest resource bottlenecks. Database replay captures production workloads to test systems with realistic data.
This document discusses how Oracle databases automatically manage space and techniques for optimizing space usage. It covers deferred segment creation, compression, monitoring tablespace usage, using the segment advisor to identify space savings opportunities, and shrinking segments to reclaim space. Resumable space allocation is also described to allow DML statements to resume if suspended due to space issues.
This document discusses managing memory in Oracle Database. It describes the different components of memory including the SGA and PGA. It emphasizes using Automatic Memory Management (AMM) and Automatic Shared Memory Management (ASMM) to automatically configure memory, rather than manual configuration. It provides guidelines for monitoring and optimizing memory usage.
This document discusses using a recovery catalog with RMAN for database backups and recovery. It covers:
1. The benefits of using a recovery catalog over just the control file, such as storing more historical data.
2. Creating a recovery catalog which involves configuring a catalog database, creating an owner, and generating the catalog.
3. Registering target databases with the catalog and maintaining the catalog's synchronization with database changes.
This document provides an introduction and schedule for an Oracle Database 11g administration course. The course objectives include configuring the database for recovery, performing backups and recovery with RMAN, using flashback technology, monitoring and tuning performance, automating tasks with the scheduler, managing space, and duplicating databases. The course will cover these topics over 5 days with lessons on backup and recovery, memory management, performance tuning, resource management, and space management. Examples will use the HR sample schema which includes tables for regions, countries, locations, departments, jobs, employees, and job history.
Flashback technology allows users to view and recover data to previous points in time. The document discusses several Flashback features: Flashback Query lets users view data as of a past time; Flashback Version Query shows row versions between times; Flashback Table recovers an entire table; and Flashback Transaction backs out changes from a problematic transaction. The document provides examples and considerations for using each Flashback feature.
This document discusses database restore and recovery tasks. It describes causes of file loss like user errors, application errors, and media failures. It also discusses different recovery operations like restoring from backups, recovering redo logs, and recovering the control file. Critical vs non-critical file losses are defined. Automatic recovery of temporary files is also covered.
This document provides a complete reference for the Server Control Utility (SRVCTL) in Oracle Database. It includes topics on using SRVCTL to manage configuration information for databases, instances, listeners, and other clusterware resources. The document outlines the SRVCTL command syntax and privileges required to perform administrative tasks. It also lists deprecated SRVCTL commands and options in Oracle Database 11g Release 2.
This document discusses using Oracle tools to manage database performance through SQL tuning. It covers using the SQL Tuning Advisor to identify and tune SQL statements that use the most resources. It also discusses using the SQL Access Advisor to tune a workload and the SQL Performance Analyzer to compare SQL performance before and after changes. The objectives are to learn to use these tools to optimize SQL performance and tune applications and workloads.
The document discusses how to automate tasks using the Oracle Database Scheduler. It describes the core components of the Scheduler including jobs, programs, schedules, and arguments. It provides examples of how to create time-based and event-based schedules. It also covers more advanced Scheduler concepts such as job chains, windows, job classes, and prioritization of jobs.
The document discusses the capabilities of RMAN, the Oracle database backup and recovery tool. It notes that RMAN offers flexibility, knowledge of database internals, data file checking, and quick recovery and cloning processes. While the syntax can be complex and there is a lack of practical knowledge, RMAN allows for efficient backups in various forms including incremental, retention settings, compression, and automatic control file backups. RMAN scripts can implement backup schedules and perform cleanup of backups and archive logs. RMAN also enables restore, recovery, point-in-time recovery, and bare database recovery. Control files store limited backup information locally while catalogs centralize information but require a catalog database.
Virtual private catalog will allow you to maintain only one recovery catalog repository by securing boundaries between administrators of various databases or between DBAs, as well as allowing you to separate their duties.
Join the Webinar to learn about Virtual Private Catalog and Demo.
Overview of RMAN
Overview of Recovery Catalog
About Virtual Private Catalog
Benefits of Virtual Private Catalog
Create Virtual Private Catalog
Manage Virtual Private Catalog
RMAN stored Script
Q& A
RMAN backup scripts should be improved in the following ways:
1. Log backups thoroughly and send failure alerts to ensure recoverability.
2. Avoid relying on a single backup and use redundancy to protect against data loss.
3. Back up control files last and do not delete archives until backups are complete.
4. Check backups regularly to ensure they meet recovery needs.
Oracle Database 12c offers new enhancements and additions in Recovery Manager (RMAN). The features listed in this article will help you transport data across platforms and reduce downtime by 8x versus tradition migration approach, recover table and table partitions to point-in-time without affecting other objects in the database, and audit RMAN-related events using unified auditing. Take advantage of these new features for efficient backup and recovery.
Yuri is called to audit RMAN backup scripts on regular basis for several years now as part of his Day to Day duties. He see the same errors in scripts that Oracle DBAs using to backup critical databases over and over again. Those errors may play a significant role in a recovery process when you working under stress. During that presentation you will be introduced to typical issues and hints how to address those.
This document provides a summary of vi editor commands organized into sections on general startup, counts, cursor movement, screen movement, inserting, deleting, copying code, find commands, miscellaneous commands, line editor mode, ex commands, substitutions, reading files, write file, moving, and shell escape. It explains how to start and exit vi, move the cursor, search for text, edit text, and use ex commands.
This document provides an overview of Oracle Data Guard Broker 12c Release 1 (12.1), including its components, user interfaces, benefits, and how it manages Oracle Data Guard configurations. It describes how the Oracle Data Guard Broker installs and works with Control File and Oracle Automatic Storage Management (ASM). The document outlines the management cycle of a broker configuration, state transitions, properties, and redo transport services.
This document discusses managing space for databases, including:
- Using 4KB sector disks and specifying disk sector sizes when creating databases, data files, and redo log files.
- Transporting tablespaces and databases between platforms using RMAN and Data Pump utilities.
- The process involves making tablespaces read-only, converting data files to the target platform format, importing metadata, and making tablespaces read/write on the target system.
This document provides an overview of how to create backups with RMAN (Recovery Manager) in Oracle. It discusses creating image file backups, whole database backups, full database backups, enabling fast incremental backups, duplex backup sets, backing up backup sets, multisection backups, archival backups, and reporting on and maintaining backups. The objectives are to learn how to perform various backup tasks with RMAN and manage those backups.
The document discusses how to configure and use the Oracle Database Resource Manager. It describes how to create resource plans and consumer groups, specify directives to allocate resources, map consumer groups to plans, activate a resource plan, and monitor resource usage. The Resource Manager allows managing resources like CPU, parallelism, sessions, and timeouts across different workload groups.
This document discusses diagnosing database issues and corruption. It covers the Data Recovery Advisor, which can detect, analyze, and repair failures. It also covers handling block corruption, setting up the Automatic Diagnostic Repository (ADR) to store diagnostic data, and using the Health Monitor to perform proactive database checks. Key topics include listing and advising on failures using RMAN, performing block media recovery, viewing ADR data with ADRCI, and running manual and automatic Health Monitor checks.
This document discusses monitoring and tuning RMAN backup and restore performance. It describes how to configure RMAN for asynchronous I/O and multiplexing, monitor job progress, identify bottlenecks, and balance backup speed versus recovery speed. Specific parameters like MAXPIECESIZE, FILESPERSET, and MAXOPENFILES are examined for their effect on performance.
This document discusses database performance monitoring and tuning. It covers monitoring sessions and services, database replay for testing, and collecting optimizer statistics. The key activities for performance management are planning, instance tuning, and SQL tuning. Performance is monitored using views for sessions, services, wait events, and statistics. Tuning involves identifying and addressing the greatest resource bottlenecks. Database replay captures production workloads to test systems with realistic data.
This document discusses how Oracle databases automatically manage space and techniques for optimizing space usage. It covers deferred segment creation, compression, monitoring tablespace usage, using the segment advisor to identify space savings opportunities, and shrinking segments to reclaim space. Resumable space allocation is also described to allow DML statements to resume if suspended due to space issues.
This document discusses managing memory in Oracle Database. It describes the different components of memory including the SGA and PGA. It emphasizes using Automatic Memory Management (AMM) and Automatic Shared Memory Management (ASMM) to automatically configure memory, rather than manual configuration. It provides guidelines for monitoring and optimizing memory usage.
This document discusses using a recovery catalog with RMAN for database backups and recovery. It covers:
1. The benefits of using a recovery catalog over just the control file, such as storing more historical data.
2. Creating a recovery catalog which involves configuring a catalog database, creating an owner, and generating the catalog.
3. Registering target databases with the catalog and maintaining the catalog's synchronization with database changes.
This document provides an introduction and schedule for an Oracle Database 11g administration course. The course objectives include configuring the database for recovery, performing backups and recovery with RMAN, using flashback technology, monitoring and tuning performance, automating tasks with the scheduler, managing space, and duplicating databases. The course will cover these topics over 5 days with lessons on backup and recovery, memory management, performance tuning, resource management, and space management. Examples will use the HR sample schema which includes tables for regions, countries, locations, departments, jobs, employees, and job history.
Flashback technology allows users to view and recover data to previous points in time. The document discusses several Flashback features: Flashback Query lets users view data as of a past time; Flashback Version Query shows row versions between times; Flashback Table recovers an entire table; and Flashback Transaction backs out changes from a problematic transaction. The document provides examples and considerations for using each Flashback feature.
This document discusses database restore and recovery tasks. It describes causes of file loss like user errors, application errors, and media failures. It also discusses different recovery operations like restoring from backups, recovering redo logs, and recovering the control file. Critical vs non-critical file losses are defined. Automatic recovery of temporary files is also covered.
This document provides a complete reference for the Server Control Utility (SRVCTL) in Oracle Database. It includes topics on using SRVCTL to manage configuration information for databases, instances, listeners, and other clusterware resources. The document outlines the SRVCTL command syntax and privileges required to perform administrative tasks. It also lists deprecated SRVCTL commands and options in Oracle Database 11g Release 2.
This document discusses using Oracle tools to manage database performance through SQL tuning. It covers using the SQL Tuning Advisor to identify and tune SQL statements that use the most resources. It also discusses using the SQL Access Advisor to tune a workload and the SQL Performance Analyzer to compare SQL performance before and after changes. The objectives are to learn to use these tools to optimize SQL performance and tune applications and workloads.
The document discusses how to automate tasks using the Oracle Database Scheduler. It describes the core components of the Scheduler including jobs, programs, schedules, and arguments. It provides examples of how to create time-based and event-based schedules. It also covers more advanced Scheduler concepts such as job chains, windows, job classes, and prioritization of jobs.
The document discusses the capabilities of RMAN, the Oracle database backup and recovery tool. It notes that RMAN offers flexibility, knowledge of database internals, data file checking, and quick recovery and cloning processes. While the syntax can be complex and there is a lack of practical knowledge, RMAN allows for efficient backups in various forms including incremental, retention settings, compression, and automatic control file backups. RMAN scripts can implement backup schedules and perform cleanup of backups and archive logs. RMAN also enables restore, recovery, point-in-time recovery, and bare database recovery. Control files store limited backup information locally while catalogs centralize information but require a catalog database.
Virtual private catalog will allow you to maintain only one recovery catalog repository by securing boundaries between administrators of various databases or between DBAs, as well as allowing you to separate their duties.
Join the Webinar to learn about Virtual Private Catalog and Demo.
Overview of RMAN
Overview of Recovery Catalog
About Virtual Private Catalog
Benefits of Virtual Private Catalog
Create Virtual Private Catalog
Manage Virtual Private Catalog
RMAN stored Script
Q& A
RMAN backup scripts should be improved in the following ways:
1. Log backups thoroughly and send failure alerts to ensure recoverability.
2. Avoid relying on a single backup and use redundancy to protect against data loss.
3. Back up control files last and do not delete archives until backups are complete.
4. Check backups regularly to ensure they meet recovery needs.
Oracle Database 12c offers new enhancements and additions in Recovery Manager (RMAN). The features listed in this article will help you transport data across platforms and reduce downtime by 8x versus tradition migration approach, recover table and table partitions to point-in-time without affecting other objects in the database, and audit RMAN-related events using unified auditing. Take advantage of these new features for efficient backup and recovery.
Yuri is called to audit RMAN backup scripts on regular basis for several years now as part of his Day to Day duties. He see the same errors in scripts that Oracle DBAs using to backup critical databases over and over again. Those errors may play a significant role in a recovery process when you working under stress. During that presentation you will be introduced to typical issues and hints how to address those.
This document provides a summary of vi editor commands organized into sections on general startup, counts, cursor movement, screen movement, inserting, deleting, copying code, find commands, miscellaneous commands, line editor mode, ex commands, substitutions, reading files, write file, moving, and shell escape. It explains how to start and exit vi, move the cursor, search for text, edit text, and use ex commands.
This document provides an overview of Oracle Data Guard Broker 12c Release 1 (12.1), including its components, user interfaces, benefits, and how it manages Oracle Data Guard configurations. It describes how the Oracle Data Guard Broker installs and works with Control File and Oracle Automatic Storage Management (ASM). The document outlines the management cycle of a broker configuration, state transitions, properties, and redo transport services.
This document contains the resume of Franck Victoria, an Oracle and MS SQL Database Administrator and Data Warehouse Performance Tuning Specialist. It outlines his extensive experience as a DBA working on various projects at companies like BNP Paribas, Rolex SA, and Alcan Aluminium Valais SA. It also lists his technical skills and certifications in databases like Oracle, MS SQL Server, and IBM DB2.
The Oracle Optimizer uses both rule-based optimization and cost-based optimization to determine the most efficient execution plan for SQL statements. It considers factors like available indexes, data access methods, and sort usage to select the optimal plan. The optimizer can operate in different modes and generates execution plans that describe the chosen strategy. Tuning the optimizer settings and database design can help it select more efficient plans.
High availability overview: Oracle Database 12cFemi Adeyemi
This document provides an overview of Oracle Database high availability features. It discusses key high availability concepts like recovery time objective and recovery point objective. It also describes several Oracle high availability solutions like Oracle Data Guard, Oracle GoldenGate, Oracle Real Application Clusters, and Oracle Automatic Storage Management. The document is intended to help readers understand how to maximize availability and protect against planned and unplanned downtime.
Oracle Database 12c - The Best Oracle Database 12c Tuning Features for Develo...Alex Zaballa
Oracle Database 12c includes many new tuning features for developers and DBAs. Some key features include:
- Multitenant architecture allows multiple pluggable databases to consolidate workloads on a single database instance for improved utilization and administration.
- In-memory column store enables real-time analytics on frequently accessed data held entirely in memory for faster performance.
- New SQL syntax like FETCH FIRST for row limiting and offsetting provides more readable and intuitive replacements for previous techniques.
- Adaptive query optimization allows queries to utilize different execution plans like switching between nested loops and hash joins based on runtime statistics for improved performance.
This document provides an introduction and overview of the Oracle Database SQL Tuning Guide. It was authored by Lance Ashdown and Maria Colgan, and is dedicated to Mark Townsend. The guide contains information about SQL processing, the query optimizer, query transformations, access paths, join methods, generating and reading execution plans, and more. It is intended to help database administrators and developers tune SQL statements for optimal performance.
Mid term & final- preparation- student-review(Oracle)than sare
This document contains a multiple choice question test with 20 questions about Oracle database concepts like instances, parameters, memory management, backups, and recovery. It also includes fill-in-the-blank and problem solving questions testing knowledge of altering profiles, control files, undo retention, tablespace properties, RMAN commands, and recovery procedures. The test is assessing understanding of key Oracle administration and troubleshooting tasks.
This document discusses using Oracle's Recovery Manager (RMAN) to perform various database recovery operations. It covers restoring and recovering lost or corrupted data files, using incremental backups to speed up recovery, switching to image copies for fast recovery, restoring a database to a new host, and recovering using a backup control file. The objectives are to use RMAN to perform complete recovery when data files are lost, recover using incremental backups, switch to image copies, restore to a new host, and recover using a backup control file.
This document discusses backup and recovery concepts in Oracle databases. It covers different types of failures that can occur, including statement failures, user process failures, network failures, instance failures, and media failures. It describes how to configure the database for recoverability through techniques like implementing the flash recovery area, multiplexing control files and redo log files, and placing the database in ARCHIVELOG mode to archive redo logs. The goal is to minimize data loss and mean time to recovery (MTTR) through redundancy and fast recovery processes.
This document discusses various methods for performing database backups, including Recovery Manager (RMAN), Oracle Secure Backup, and user-managed backups. It covers key backup concepts like full versus incremental backups, online versus offline backups, and image copies versus backup sets. The document also provides instructions on configuring backup settings and scheduling automated database backups using RMAN and Enterprise Manager.
Checkpointing saves database status and changes to data files. It reduces recovery time after a fault. Regular checkpointing is performed automatically or manually. Reasons redo logs may not delete after checkpointing include active transactions or archiving in Archivelog mode. Media recovery restores missing or corrupted data files using backups, archive logs, and log anchor files in Archivelog mode.
RMAN is an Oracle tool that performs physical backups and recovery of Oracle databases. It can perform full backups as well as incremental backups. Incremental backups only back up changed blocks since the previous backup. RMAN also allows recovery of individual datafiles, tablespaces, or the entire database using backups. It facilitates various recovery scenarios including datafile recovery, tablespace recovery, and disaster recovery when all files are lost.
The document provides guidance on different backup and recovery scenarios for both user-managed and RMAN-managed recovery in Oracle databases. It lists 7 user-managed recovery scenarios including recovering a missing system tablespace, non-system tablespace, or datafile. It also covers control file recovery and incomplete recovery up to a point in time or log sequence. For RMAN recovery, it recommends configuring automatic backups and retention policies and describes using RMAN to backup datafiles, control files, and archive logs.
The document discusses database backup and recovery basics. It defines redo log files and archived log files, with redo logs recording changes made to the database for recovery and archived logs copying redo log contents for recovery. It also covers the goals of database administrators to keep databases available, types of backups (physical and logical), categories of failures (media failures and user errors), configuring for recoverability including archive log files, and the differences between no archive log mode and archive log mode.
The document discusses different scenarios that can occur when redo logs are lost or deleted from an Oracle database. It describes 4 main scenarios: 1) when a redo log is archived, 2) when a redo log is not archived, 3) when the current redo log is lost during a clean shutdown, and 4) when the current redo log is lost during an unclean shutdown. For each scenario, it provides the steps to recover the database, which may involve restoring from backup and opening the database with RESETLOGS.
Oracle database hot backup and recoveryArun Sharma
Oracle database hot backup and recovery process. Please note that this method is no longer used in real-time as RMAN does way better job at database backup & recovery.
This is just good to know activity but do not implement it in real time. Knowing how Oracle hot backup and recovery process works, it helps you understand Oracle RMAN better.
Here is the full link of article: https://www.support.dbagenesis.com/post/oracle-database-hot-backup-and-recovery
24 HOP edición Español - Sql server 2014 backup encryption - Percy ReyesSpanishPASSVC
Veremos la mejora en seguridad que significa usar Backup Encryption en SQL Server 2014 así como también su impacto en el rendimiento y sus escenarios de usos.
This document discusses Oracle database backup and recovery. It covers the need for backups, different types of backups including full, incremental, physical and logical. It describes user-managed backups and RMAN-managed backups. For recovery, it discusses restoring from backups and applying redo logs to recover the database to a point in time. Flashback recovery is also mentioned.
- Database backups are important to prevent data loss from hardware failures, user errors, or application issues. Regular backups should include the database contents, log files, and configuration information.
- Common backup methods include using mysqldump to dump databases into SQL files, copying table files, making delimited text file backups, and enabling binary logging for incremental backups by replaying log files.
- Backups should be stored in multiple locations including on separate disks, servers, or cloud storage. A backup strategy includes performing full and incremental backups on a schedule as well as before and after structural changes.
1) The document discusses different methods for backing up an Oracle database, including using RMAN from the command line or Enterprise Manager GUI, and configuring the backup environment.
2) It provides step-by-step instructions for backing up an Oracle database that is in ARCHIVELOG or NOARCHIVELOG mode using RMAN, either via the CLI or the EM GUI.
3) The document also covers using Oracle's Flashback feature to enable point-in-time recovery of the database if unwanted changes are made, and provides steps for enabling Flashback via SQL*Plus or the EM.
Backup and recovery procedures protect databases from data loss by allowing reconstruction of data through media recovery operations if loss occurs. A backup is a copy of important database files and data that acts as a safeguard against unexpected data loss or errors, enabling reconstruction using the backup if the original data is lost. Backups can be physical, copying database files, or logical, extracting data for storage in binary files. Oracle provides two main methods for backup and recovery: Recovery Manager (RMAN) and user-managed backup and recovery.
The document provides an overview of database backup, restore, and recovery. It describes various types of failures that may occur including statement failures, user process failures, instance failures, media failures, and user errors. It emphasizes the importance of defining a backup and recovery strategy that considers business requirements, operational requirements, technical considerations, and disaster recovery issues to minimize data loss and downtime in the event of failures.
The document discusses database backup and recovery techniques. It defines database backup as backing up the operational state, architecture and stored data of a database to create a duplicate instance in case of crashes or data loss. It describes different backup methods like transaction log backups and full backups. It also discusses the importance of backups to restore data after damage or deletion. The document then covers different types of backups like full, incremental and differential backups. It further discusses database recovery, causes of database failures, and solutions like log-based recovery and shadow paging. Finally, it discusses the importance of backups and recovery for business continuity.
Types of Backup and Recovery Practices
There are two methods you can use to recover your database. You can use RMAN, and take advantage of its automatic recovery capabilities. It can restore the appropriate files and bring the database back to a current state by using very few commands. You can also recover manually. This is called user-managed recovery. User-managed recovery entails moving the files around using OS commands, and then issuing the recovery commands in SQL*Plus.
Both of these methods use restore and recovery processes.
Performing a User-Managed Backup of the Database
You can back up the database by using OS commands to make copies of the data files. The course of action depends on whether the database is in ARCHIVELOG mode or not. If it is, then you can keep the database open and available by putting each tablespace into backup mode before copying its data files. Otherwise, you have to shut down the database before copying the data files.
The Need for Backup Mode
When a block is being written to as part of the execution of a data manipulation language (DML) statement, there could be several parts of the block affected. Not all of the modifications to the block happen at the same time, so there is the possibility of inconsistency in the block at certain times. Suppose time t2 represents the time between when different parts of the block are written to. If, at time t2, the block is copied as part of the execution of an OS copy command, then the block is considered fractured. Also, the OS copy command does not necessarily copy the file header first, so it must be frozen for the duration of the copy execution.
RMAN has the means to deal with this problem. If a fractured block is read, it keeps rereading it until it is consistent.
However, if an OS command such as the Linux cp command is copying the data file, the fractured block is not recognized as such, and the copy of the block is not consistent. In order to remedy this, put the tablespace, or even the entire database, into what is called backup mode. The effect of doing this is that additional redo is generated. An image of each block, before it is modified, is written to the redo log. Then, during recovery of blocks in that data file, the before image of a fractured block can be used for the basis of recovery and the additional redo data is applied to it. In order to reduce the overhead associated with maintaining extra redo data, Oracle recommends putting one tablespace at a time into backup mode, while its data files are being copied.
Identifying Files to Manually Backup
User-managed backups require you to know the data file names and locations on disk, so you know what files need to be copied. Identify the data files to be backed up by querying the V$DATAFILE view. Identify the control file location by querying the V$CONTROLFILE view. Only one of the multiplexed control files needs to be backed up, because they are identical.
Manually Backing Up a NOARCHIVELOG Database
You can make a consistent, whole database backup of a NOARCHIVELOG database by shutting down the database and copying all the data files and the control file to a backup directory. Because the action of copying the files is done using OS commands (in this case, the Linux cp command), the database must be shut down first. This puts it in a consistent state. If your database is running in NOARCHIVELOG mode, this is your only option. Otherwise, in ARCHIVELOG mode, you can make inconsistent backups, which allows you to leave the database running while you take the backup.
Manually Backing Up an ARCHIVELOG Database
If the database is in ARCHIVELOG mode, then you do not necessarily have to shut it down before copying the files. You end up with an inconsistent backup, but the application of redo data recovers it to a consistent state.
Starting Backup Mode: You do have to put each of the data files into backup mode before copying them, though. Do this using the BEGIN BACKUP clause of the ALTER TABLESPACE and ALTER DATABASE commands. Here is the syntax for each:
ALTER TABLESPACE <tablespace> BEGIN BACKUP;
ALTER DATABASE BEGIN BACKUP;
The ALTER TABLESPACE command affects only those data files that belong to that tablespace. ALTER DATABASE affects all data files in the database.
Ending Backup Mode: It is important to bring the data files out of backup mode. You cannot have any data files in backup mode at the time the database is shut down. If you attempt to shut down the database in that state, you will receive an error. Also, because backup mode causes additional redo to be generated, there is extra load on the system. There is no reason to have any data files in backup mode if you are not actively backing them up.
Note: In addition, you need to archive out the current redo log files, and back them up safely as well.
Backing Up the Control File
You should back up the control file every time you make a structural change to the database. Use one of the commands shown in the slide to do this. The first command creates a binary copy of the file. You can optionally supply the REUSE keyword if the backup file already exists and you want to overwrite it.
The second command makes a plain text version of the control file, which is actually a script that creates the control file when run. The resulting script is written to the diagnostics trace directory, such as:
$ORACLE_BASE/diag/rdbms/orcl/orcl/trace
You can also specify a name for the trace file by using the AS 'filename' clause.
Performing Complete Database Recovery: Overview
Complete database recovery brings the database back to its most current state. You can recover the entire database, or a single tablespace or data file at a time. You must have a current or backup control file in order to perform complete database recovery. You must also have backups available for all files in need of media recovery or you must have all archived redo log files that were generated since the data file was added to the database. Refer to the Oracle Database Backup and Recovery User’s Guide for additional information about re-creating data files when backups are not available.
You must have all the archive logs available, from the point in time the backups were taken, to the present. If you do not have all of them, you can recover only to the last point in time when redo is available. If no archive logs are required, then only online redo logs are applied.
Query the following views:
V$RECOVER_FILE: To see which files need media recovery
V$RECOVERY_LOG: To see which archive logs are required to perform recovery
Performing Complete Closed Database Recovery: Overview
Under certain circumstances, such as damage to a file belonging to the SYSTEM tablespace, the instance shuts down automatically. Even if the instance keeps running, and there are problems with other data files, you may decide there is no value is keeping the database running; too many database objects are affected. In that case, shut down the database to perform the recovery.
If the database is still open, you can query the V$RECOVER_FILE view to see which data files are in need of recovery, and after you restored them, query V$RECOVERY_LOG to see which archive logs are required. That will tell you which files need to be restored from backup, if any.
Then shut down the database. Look into the media failure to determine the cause of the problem. Repair the problem so that you can restore the files from backup. For example, you may need to replace a disk drive.
Now you can perform the recovery using the RECOVER command. Limit the scope of the recovery to only what is needed, such as data file or tablespace. If needed, recover the entire database. Then open the database.
Identifying Recovery-Related Files
If the database is still open, query the files as described below. Otherwise, attempt to start the instance and mount the database to issue the queries.
In order to determine which data files require recovery, query the V$RECOVER_FILE view. The ERROR column indicates why the file requires recovery. If this column has any value other than OFFLINE NORMAL, then it needs recovery. To see the whole picture of which data files and tablespaces are affected, join V$DATAFILE and V$TABLESPACE in this query. Here is an example:
SELECT r.FILE#, d.NAME df_name, t.NAME tbsp_name,
d.STATUS, r.ERROR, r.CHANGE#, r.TIME
FROM V$RECOVER_FILE r, V$DATAFILE d, V$TABLESPACE t
WHERE t.TS# = d.TS#
AND d.FILE# = r.FILE#;
This tells you the extent of the damage, helping you decide what the objects of the RECOVER command should be.
The V$RECOVERY_LOG view shows which archive log files are needed to perform the recovery. If the list shows files that have since been moved off the default archive log location, then you have to restore them to some location before performing recovery.
After recording the results of these queries, shut down the database.
Restoring Recovery-Related Files
After determining what data files and archive log files are required, restore them to appropriate disk locations. Restore a data file by copying it from the backup location, as in this example:
$ cp /disk2/backup/datafile/survey01.dbf \> $ORACLE_BASE/oradata/ORCL/datafile/survey01.dbf
If any archive logs are needed for recovery, check whether they are still in the default disk location for archive logs. They may not be, if they have been moved to tape or another disk drive, for example. If they have been moved, they need to be restored, either to the default archive log location or to a temporary location. If there is enough space available in the default location (which is specified by the LOG_ARCHIVE_DEST_1 initialization parameter), then restore them there. Otherwise, you can put them on some other disk location. When it is time to restore, you can specify that alternate location to find archive log files.
If you had to move a data file, that fact has to be recorded in the control file. That is done by executing the ALTER DATABASE RENAME FILE command, as shown in the following example:
SQL> ALTER DATABASE RENAME FILE
2> '/u01/app/oracle/oradata/ORCL/datafile/survey01.dbf' TO
3> '/newdisk/ORCL/datafile/survey01.dbf';
Note: You must start the instance and mount the database before executing the ALTER DATABASE RENAME FILE command.
Restoring Recovery-Related Files (continued)
If you have not yet done so, mount the database and bring all the data files online. You can check the status of each data file by querying the V$DATAFILE view. Bring the data files online by using a command like the following:
SQL> ALTER DATABASE DATAFILE \
2 > '/newdisk/ORCL/datafile/survey01.dbf' ONLINE;
Applying Redo Data
Now the data files have been restored to some point in the past. The archive log files have also been restored: either to their default location or to some other location, for the purpose of this recovery only. You are ready to perform the actual recovery step, which means the redo is applied and the data files are brought up to the latest SCN. Do that using the SQL*Plus RECOVER command.
If you do not specify the AUTOMATIC option, then you are prompted for each redo log file that is about to be applied. That gives you more control over the recovery process. Typically, AUTOMATIC is used for full recovery.
If the archive log files have been restored to some disk location other than the default for the database, then you must specify the FROM clause. Supply the directory where the files are stored, and the recovery process will look there for the files.
Finally, open the database. It is now fully recovered.
Performing Complete Open Database Recovery
If media failure occurs while the database is open, the database continues to function. When an attempt is made to write to one of these data files, the data file is taken offline automatically. A query against one of these data files does not cause it to go offline, but it does result in an error being returned to the user that issued the query.
As with the closed database recovery, you first need to query for the files and archive logs that need to be recovered. Then, take all tablespaces that contain damaged data files offline. Use a command such as the following to do this:
SQL> ALTER TABLESPACE survey OFFLINE TEMPORARY;
Using the TEMPORARY option causes Oracle to perform a checkpoint on any online data files belonging to the tablespace. Checkpointed data files do not require recovery when they are brought back online, because they are up-to-date for the latest SCN of any transactions that would have affected them. This is the more desirable option, although the data files must be available at the time this command is run. It is possible that the problem was temporary, and you are able to bring the tablespaces online with no errors.
Performing Complete Open Database Recovery (continued)
Inspect the media to determine the cause of the problem. You can use the DBVERIFY utility for this. If the files are permanently damaged, then proceed to restore and recover as described for the closed database recovery earlier in this lesson. After the restore and recovery steps are complete, bring all the tablespaces online again.
Note: For more information about the DBVERIFY utility, see the Backup and Recovery User’s Guide.
Performing User-Managed Incomplete Recovery: Overview
An incomplete recovery is one that does not bring the database back to the most recent SCN that was transacted. For some reason, as listed in the slide, you need to recover that database only up to a point in the past, not to the present. The processing that occurs when performing incomplete recovery differs from the processing for complete recovery, basically, in the amount of redo that is applied.
Choosing an Incomplete Recovery Method
As you plan your incomplete recovery, decide which method you want to use for specifying when to stop applying redo data. You stop the recovery process by specifying one of the following:
A time: The time in the logs at which recovery should stop. This can be automated so that the process does not prompt you for each file name.
An SCN: The system change number at which recovery should stop. This can be automated so that the process does not prompt you for each file name.
CANCEL: Specify the CANCEL keyword when the recovery process prompts for the next redo log file name. You cannot automate this process because you must specify CANCEL to terminate the recovery operation.
Performing User-Managed Incomplete Recovery
The following command is used to perform incomplete recovery:
RECOVER [AUTOMATIC] DATABASE option
Following are the meanings of the options:
AUTOMATIC: Automatically applies archived and redo log files
option: UNTIL TIME 'YYYY-MM-DD:HH24:MI:SS'
UNTIL CANCEL
UNTIL CHANGE <integer>
USING BACKUP CONTROLFILE
Cancel-Based Incomplete Recovery
Cancel-based incomplete recovery is very much like closed database complete recovery. The difference is how you execute the RECOVER command; specify the UNTIL CANCEL clause. This clause causes the recovery process to prompt you with the suggested name for each redo log file to be applied. So, as the recovery proceeds, you are prompted with an archived or online redo log file name, and, for each one, you can either accept it or change it. When you reach the point where you want the recovery to stop, enter CANCEL instead of accepting the file name. This stops the recovery.
After this is done, you have to open the database with the RESETLOGS option. The database is in another instantiation now, so the redo log sequence numbers need to be reset.
Performing User-Managed Incomplete Recovery (continued)
After opening the database, check the alert log for messages. This is how you find out if the recovery was successful.
Time- and Change-Based Incomplete Recovery
Both time- and change-based incomplete recovery are like the cancel-based recovery, except that different criteria are used to specify when to stop the recovery. Time-based recovery uses a time specified on the command line of the RECOVER command, to know when to stop. Change-based recovery uses an SCN, specified on the command line.
As with all incomplete recoveries, the database must then be opened using the RESETLOGS option.
Note: To apply redo log files automatically during recovery, you can use the SQL*Plus SET AUTORECOVERY ON command, enter AUTO at the recovery prompt, or use the RECOVER AUTOMATIC command.
Performing User-Managed Incomplete Recovery: Steps
1.If the database is open, shut it down by using the NORMAL, IMMEDIATE, or TRANSACTIONAL option.
2.Restore all data files from backup. You must use a backup taken before the time you plan to recover to. You may also need to restore archived logs. If there is enough space available, restore to the LOG_ARCHIVE_DEST location or use the ALTER SYSTEM ARCHIVE LOG START TO <LOCATION> command or the SET LOGSOURCE <LOCATION> command to change the location. If you perform incomplete recovery to a point when the database structure is different than the current, you also need to restore the control file.
Mount the database.
4.Recover the database by using the RECOVER DATABASE command.
5.To synchronize data files with control files and redo logs, open the database by using the RESETLOGS option.
User-Managed Time-Based Recovery: Example
The following is a typical scenario employing UNTIL TIME recovery. Assume the following facts:
The current time is 12:00 PM on November 28, 2005.
A job was run incorrectly, and many tables in several schemas were affected.
This happened at approximately 11:45 AM.
Database activity is minimal because most staff are currently in a meeting. The state of the database before the job ran must be restored.
Because the approximate time of the error is known and the database structure has not changed since 11:44 AM, you can use the UNTIL TIME method:
1.If the database is open, shut it down by using the NORMAL, IMMEDIATE, or TRANSACTIONAL option.
2.Restore all data files from backup (the most recent if possible). You may also need to restore archived logs. If there is enough space available, restore to the LOG_ARCHIVE_DEST location or use the ALTER SYSTEM ARCHIVE LOG START TO <LOCATION> command or the SET LOGSOURCE <LOCATION> command to change the location.
3.Mount the database.
User-Managed Time-Based Recovery: Example (continued)
4.Recover the database:
SQL> recover database until time '2005-11-28:11:44:00'
ORA-00279: change 148448 … 11/27/05 17:04:20 needed for thread ...
Media recovery complete.
5.To synchronize data files with control files and redo logs, open the database by using the RESETLOGS option:
SQL> alter database open resetlogs;
SQL> archive log list
...
Oldest online log sequence 0
Next log sequence to archive 1
Current log sequence 1
When recovery is successful, notify users that the database is available for use, and any data entered after the recovery time (11:44 AM) will need to be reentered.
User-Managed Cancel-Based Recovery: Example
After searching through the directory for the redo log files, you notice that redo log log2a.rdo cannot be located and has not been archived. Therefore, you cannot recover past this point.
Querying V$ARCHIVED_LOG confirms the absence of archived log sequence 48 (log2a.rdo):
SQL> SELECT * FROM v$archived_log;
RECIDSTAMP ... FIRST_CHANGE#FIRST_TIME
--------------... -----------------------
1318531466... 88330 05-11-15:12:43
47319512880... 309067 05-11-28:11:26
User-Managed Cancel-Based Recovery: Example (continued)
The steps for cancel-based recovery are the same as for time-based recovery, except for the RECOVER DATABASE step. When the RECOVER DATABASE UNTIL CANCEL command is executed, it recovers the database until it cannot find a log file. When you are prompted for the name of the missing archived redo log file, enter CANCEL; the recovery stops at that point in time.