Veeam Backup & Replication v8: Availability for Oracle Environments

Transcription

1 Veeam Backup & Replication v8: Availability for Oracle Environments Luca Dell Oca EMEA Evangelist at Veeam,vExpert, VCAP-DCD, CISSP

2 Contents 1. Executive summary Introduction Audience Purpose Oracle overview Oracle architecture overview How a write happens in Oracle Data consistency via SCN Redo logs and archive logs Main Oracle deployment types RAC and SCN consistency ASM (Automatic Storage Management) RMAN (Recovery Manager) Oracle Data Protection overview Data protection scenarios Which components to protect alert.log Parameter file Control File Data Files Redo log files Archive log files

3 5. Data protection scenarios Backup of the entire Windows VM Database consistency by scripts Veeam Backup & Replication v8 Patch Veeam Backup & Replication v8 or v Data protection with RMAN...22 Veeam protecting RMAN backups Veeam integration with RMAN scripts Enable archive logs ControlFile Autobackup Start RMAN with external catalog database RMAN backup example Restore examples Restore from backups using scripts Restore from RMAN About the Author...28 About Veeam Software

4 1. Executive summary Virtualized environments have gone a long way, and in the latest years there have been massive improvements in terms of performances and capabilities. Thanks to the undoubtful advantages of virtualization together with the newest versions of the hypervisors capable of running the largest possible workloads, so called "business critical applications" (BCA) have been moved from physical environments to virtualized platforms without issues, experiencing all the benefits of virtualization. No longer is virtualization just about server consolidation and footprint reduction it s the platform of choice for "Tier 1" applications, but also for the agility and high availability (HA) it offers, and the fine resource management it brings. For all these reasons and more, enterprise applications like Microsoft SQL Server or Exchange, SAP and Oracle are commonly executed on virtualized environments today. Oracle databases are among the most important applications in many environments. Relational databases are used for custom applications developed internally by a company, or as a database backend for commercial applications deployments. In both scenarios, data registered in Oracle databases require a proper design for their availability needs. This involves specific virtualization capabilities like HA, and proper data protection. Availability for BCA is not something that can be applied afterwards as an add-on, but instead a critical component that should be planned for and designed into the overall plan. Veeam Backup & Replication v8, part of Veeam Availability Suite, guarantees a high degree of availability for Oracle databases by leveraging its capabilities, especially data loss avoidance, verified protection and high-speed recovery. 4

5 2. Introduction 2.1 Audience This document is intended for use by individuals working in companies using Oracle databases in virtualized environments. Regardless of roles database administrators, virtualization specialists, storage or network managers, or data protection admins this document is a useful source of information for best practices on data protection for Oracle databases. The document will specifically describe VMware vsphere environments, since it's the preferred platform for Oracle deployments, but the best practices described here can be successfully applied also to Microsoft Hyper-V environments and both are fully supported by Veeam Availability Suite v Purpose This document describes best practices for data availability of Oracle deployments in virtualized environments, leveraging Veeam Availability Suite v8. Depending on your business needs, some suggestions may require changes to be applied, and each environment should be carefully evaluated against the official documentation of both the hypervisor vendors (VMware or Microsoft) and Oracle itself, or also the application using Oracle as a backend database. Licensing will not be covered in this document; each environment and all its components should be properly licensed. Please refer to different involved vendors licensing rules and guides for further details. In this document we will describe protection scenarios supported by Oracle. Third-party applications using Oracle as their backend database may not support one or more of the described scenarios, or suggest their own in addition. Please check with your application vendor for which scenarios are supported. 5

6 3. Oracle overview Oracle databases deployed in virtualized environments require the involvement of different professionals in the company. These people may be spread among different teams in large companies, or it could be the same IT professional in small environments. Regardless of the size of the deployment, any Oracle environment requires a set of skills to properly understand how it works and how it can be successfully protected. Oracle touches many components of a virtualized environment: storage, networking, virtualization, and data protection are all involved in an Oracle deployment. For this reason, this first chapter will give you a high-level overview of Oracle technology. If you are already an experienced Oracle administrator, you can safely jump to the next chapter. 3.3 Oracle architecture overview For people who are not acting as Oracle database admins in a company, it's nonetheless important to understand, at least at a high level, how Oracle works. This knowledge is important in order to properly: interact with DBAs and other stakeholders (especially during the design of Oracle data protection solutions), have a comprehensive view of how Oracle can be protected, use which tools in which scenarios, know which files and folders need to be saved for a complete and successful restore, and work together with DBAs and line of business owners to define the desired recovery time and point objectives (RTOs and RPOs) and configure Oracle and Veeam Backup & Replication to best fulfill the agreed upon service level agreements (SLAs). Oracle is a relational database management system (RDBMS), and an Oracle installation consists of an Oracle database and an Oracle instance (figure 1). Figure 1 6

7 An Oracle instance is the combination of background processes and memory structures. The instance must be started in order to access data in the database. Every time an instance is started, a System Global Area (SGA) is allocated and Oracle background processes are started. Background processes perform input/output (I/O) and monitor other Oracle processes to provide increased parallelism for better performance and reliability. An Oracle database consists of database files that provide the physical storage for database information. Database files are used to ensure that data is kept consistent and can be recovered in the event of a failure of the instance. There are finally some key files (usually non-database files) that are used to configure the instance, authenticate and authorize users, and recover the database in the event of a disk failure, like the redo logs and archive logs How a write happens in Oracle It's important to understand the "journey" a write activity takes into Oracle, from start to finish, in order to better learn how the different components of an Oracle database are used and how Oracle guarantees consistency and protection of stored information. This will be important at a later stage to clearly identify where data is stored in order to plan for data protection. Let's assume a client application wants to update a row in a table of the database; here's the process: 1. The application connects to the Oracle instance. 2. The user/application executes a SQL statement, and this becomes a transaction inside Oracle. 3. The server checks for the privileges of the user requesting the transaction. If privileges are not sufficient, the transaction is denied. 4. The server checks the shared SQL area if the same transaction is already stored there. If so, it's reused without writing the new one. Otherwise, the SQL statement is written in a new shared SQL area to be used. 5. The server checks if needed data is already in the buffer cache; otherwise, data is retrieved from the database file. (Effectively, buffer cache is a read/write cache.) 6. The server modifies data in the buffer cache applying the SQL statement. 7. Log Writer (LGWR) immediately writes a copy of the transaction into a Redo Log. 8. Database Writer (DBWR) permanently processes data and modifies the relevant data blocks in the database file. 9. When the transaction is committed to the Redo Log, Oracle server reports back the result of the activity to the user/application; writes to the database files can happen at a later time. 10. If the commit is not successful, an error message is registered and transmitted. 11. If Archive Log is enabled, at Redo Log rotation the inactive Redo Log is also stored in an Archive Log. 7

8 The activity flow can be represented like in this diagram (figure 2). Figure Data consistency via SCN In database technologies, a single logical operation on the data is called a transaction. One of the characteristics that a database system needs to guarantee with regard to transactions is consistency: this property ensures that any transaction will bring the database from one valid state to another. In Oracle, the primary mechanism to guarantee consistency is SCN (System Change Number). SCN is used in different areas, such as: Every redo record has an SCN version of the redo record in the redo header (and redo records can have non-unique SCN). Given redo records from two threads (as in the case of RAC), Recovery will order them in SCN order, essentially maintaining a strict sequential order. Every data block also has block SCN (aka block version). In addition, a change vector in a redo record also has expected block SCN. This means that a change vector can be applied to only one version of the block. Code checks if the target SCN in a change vector is matching with the block SCN before applying the redo record. If there is a mismatch, corruption errors are thrown. Read consistency also uses SCN. Every query has query environment which includes an SCN at the start of the query. A session can see the transactional changes only if that transaction commit SCN is lower than the query environment SCN. Every commit will generate SCN (aka commit SCN) that marks a transaction boundary. 8

9 SCN is a huge number with two components to it: base and wrap. Wrap is a 16-bit number and base is a 32-bit number. The final format is wrap.base. When base exceeds 4 billion, then the wrap is incremented by 1. Essentially, wrap counts the number of times base wrapped around 4 billion. So, SCN has a limit but is so high that is basically impossible to run out of SCNs. (maximum value of wrap * 4 billion = 65536* 4* (2^30) = 281,474,976,710,656 = 281 trillion) SCNs are also important from a data protection point of view. You will learn in this document, there are two main methods for protecting Oracle databases. If you decide to use hot backup mode on Oracle 11g, please check with your DBA you are not incurring the situation described in Oracle Document ID This could generate a high number of SCNs after the database has been placed in hot backup mode. There is a patch available to fix this problem (patch ); you are invited to apply it, or to use "alter tablespace" if you cannot apply the patch for any reason Redo logs and archive logs Redo logs are pre-allocated files responsible for storing all changes made to a database as they occur in a proprietary format. Every instance of an Oracle database has two or more redo logs associated with it to protect the database in case of a failure. Every operation executed against a database is first recorded in the redo log buffer, then the log writer process assigns an SCN and writes the data to the Redo Log, together with the information and data regarding a given transaction. A redo log is the primary target for database commits: a user receives a "commit complete" message only when the transaction is successfully recorded in a redo log. In order to reduce disk I/O and improve performance, commits are recorded first in the log buffer, residing in memory, but the final commit is issued only when the commit is recorded in the redo log on a non-volatile medium, such as disk. If a database crashes, the recovery process reads all the information stored in the redo logs (committed or not), and applies them to the data files on disk. Oracle replays all the transactions with a "begin entry" (the point in time a transaction started and was recorded in the redo log) and a "commit entry" (the point in time a transaction has been committed and has received an SCN). At the same time, all transactions with a begin entry but without a commit entry are undone in the database. Redo logs can be really verbose, depending on the number of transactions and their frequency. For these reasons, Oracle can be configured to have multiple logs and to rotate continuously between them. Once a log is filled, Oracle stops writing to it and starts using the next one. When all the existing logs are filled, it starts using the first one again, overwriting its content. Logs are also protected from unsafe overwrites. A log is not allowed to be overwritten until all of its changes have been written to the data files, and if archive mode is enabled, until it s also archived. For performance tuning, is important that an Oracle database has enough redo logs to sustain its transaction activities, and also to guarantee enough history of the transactions themselves. However, if an Oracle user wants to extend the retention of logs, there is another method to archive logs, and it's the "archive logs" solution. With it, redo logs are archived outside of the log rotation, they are not overwritten, and they can be stored in multiple different location to offer additional protection. 9

10 Archive logs are not configured by default in Oracle. Once they are enabled, they allow for point-intime recovery operations, down to a single transaction. Their creation is quite simple at any redo log rotation, the just filled redo log is copied in the specified destination, and it becomes an archive log. 3.2 Main Oracle deployment types Based on the number of instances and databases in an Oracle server, we can identify two main deployment modes for Oracle (figure 3). Single Instance: one instance accessing a given database RAC (Real Application Cluster): more than one instance accessing the same database simultaneously Figure 3 A single Oracle Server can have multiple instances accessing different databases, all running in the same guest OS of a virtual machine (VM), but we will not include this scenario in this paper. From a virtualization point of view, these two main scenarios can be described as follows: A single instance Oracle Server is a single VM, where one Oracle instance is accessing one Oracle database. A RAC is made of multiple VMs, each of them executing one or more instances, and all accessing a shared volume concurrently, where database files and other files are stored. Note: Additional deployment modes are available for Oracle, such as RAC One Node. These modes will not be discussed in this paper. 10

11 3.2.1 RAC and SCN consistency As explained in Chapter 3.1.2, Oracle uses a logical timestamp known as a system change number (SCN) to order data block change events within each instance and across all instances. The main purpose of SCNs is to mark redo log entries in a way they can be later synchronized during recovery processing. Oracle assigns an SCN to each transaction. In a single instance scenario, the System Global Area (SGA) maintains and increments SCNs from an instance that has mounted the database in exclusive mode. In Real Application Clusters, the SCNs must be maintained globally and its implementation can vary by platform. SCNs can be managed by the GCS (Global Cache Service), by the Lamport SCN generation scheme, or by using a hardware clock or dedicated SCN server. 3.3 ASM (Automatic Storage Management) Oracle files can be stored in a regular file system available on the underlying OS where Oracle itself is installed, or it can leverage ASM. Automatic Storage Management (ASM) is Oracle's logical volume manager and file system at the same time. First introduced with the Oracle 10g Release 1, it s the successor to the Oracle Cluster File System (OCFS - OCSF2), and it was specifically designed to support Oracle databases, not as a general file system. ASM is designed to offer DBAs a storage management interface directly inside the database management tools, while abstracting any underlying storage resource to the application, and offers common features like: Management of underlying disk devices (no disk partitioning needed) Add and remove space dynamically Storage migrations between disks Share the same disk (or disk group) between databases Striping: spread I/O over all available disks Mirroring: ASM can maintain redundant copies of data with different protection levels: Normal for 2-way mirroring High for 3-way mirroring External which skips ASM mirroring, such as when you configure hardware RAID for redundancy. This is the preferred method on virtualized environments when there is a backend storage array that is already self-protected. 11

12 An Oracle ASM instance is built on the same technology as an Oracle database instance. An Oracle ASM instance has a System Global Area (SGA) and background processes that are similar to those of Oracle databases. However, because Oracle ASM performs fewer tasks than a database, an Oracle ASM SGA is much smaller than a database SGA. In addition, Oracle ASM has a minimal performance effect on a server. Oracle ASM instances mount disk groups to make Oracle ASM files available to database instances; Oracle ASM instances do not mount databases. Also, ASM instances can be clustered too, like RAC clusters, using Oracle Clusterware. There will be one Oracle ASM instance in each of the cluster nodes. ASM is available with no additional license in any Standard or Enterprise versions of Oracle, and while it was designed mainly for RAC deployments, it can be used in any Oracle deployment. Finally, Oracle databases (and their own tablespaces and data files) can be migrated from standard file systems to ASM (and vice versa) using backup and restore procedures involving RMAN, or using dedicated wizards in Oracle Enterprise Manager. 3.4 RMAN (Recovery Manager) Oracle RMAN (Recovery Manager) is a backup and recovery manager supplied by Oracle (since version 8). RMAN has command line and graphical capabilities (via Oracle Enterprise Manager) for configuration and daily operations. This component is deployed by default during any Oracle installation, and it does not require additional licenses to be used. RMAN has different components, some mandatory: Target database: This is the registered database inside RMAN, on which RMAN is performing backup and recovery operations. All operations performed by RMAN against this database will be logged in its database control file. RMAN client: This is the executable required to run RMAN and perform the desired tasks. It's installed automatically in the /bin directory of any Oracle installation. And other optional components: Fast Recovery Area: also called Flash Recovery Area or FRA, it's the storage location (a directory on disk or a disk group in ASM) that contains redo logs, control files, archived logs, backup pieces coming from RMAN and copies, flashback logs and, from 11g, foreign archived logs. This area was first introduced in Oracle 10g. FRA can be controlled by specifying its location and size according to user s convenience. Media Manager: This is responsible for communications between RMAN client and media like tape, etc. It's also responsible for managing media during operations like backup and recovery, media loading, media labelling and unloading. Recovery Catalog: This is a dedicated database, that records and holds all RMAN activities on one or more target databases. 12

13 4. Oracle Data Protection overview In the previous chapter, we described a series of deployment modes, features and options that can be used in an Oracle deployment. When it comes to protect an Oracle database system running in a virtualized environment, those design choices will affect the available and preferred options for data protection. In this short chapter, we will describe the decisions that could be taken before initiating a data protection activity, and which components needs to be protected in order to guarantee proper recoveries. 4.1 Data protection scenarios Two main purposes in regards of Oracle workloads can be identified: Whole VM protection: By protecting the VMs where Oracle instances are executed, it's possible to plan for complete machine restores and disaster recovery scenarios involving replication Database protection: by protecting the relevant Oracle database files described in the previous chapters (especially the data files and redo/archive logs), a company can restore data inside a given database to a specific point in time. The protection of the whole VM is simple. However, the protection of the database information has different possible scenarios, depending on the way Oracle has been deployed. We can represent these methods in this flowchart (figure 4): Figure 4 13

14 4.2 Which components to protect Regardless of the scenario, there is a list of components that needs to be properly protected in any Oracle deployment in order to guarantee data loss avoidance and proper recovery alert.log Default location: Oracle_Base\rdbms\log\alert_SID.log The alert log file (also referred to as the ALERT.LOG) is a chronological log of messages and errors written out by an Oracle database. Typical messages found in this file are: database start up, shutdown, log switches, space errors, etc. This file should constantly be monitored to detect unexpected messages and corruptions. Even if this file is not needed during restore operations, DBAs usually rely on this file when something has happened to an Oracle instance, so it's also important to save it during data protection operations in order to document the integrity of the actual restore point Parameter file Default location: Oracle_Base\dbs\initSID.ora Parameter file is used to tune various instance parameters for memory usage, etc. Oracle offers two types of parameter files: INIT.ORA and SPFILE. PFILEs (also known as INIT.ORA files) are at client side and text-based. SPFILEs, are at server side, written in binary format, and can be edited by issuing ALTER SYSTEM SET commands Control File Default location: Oracle_Base\oradata\SID\control01.ctl A control file is a small binary file. It is used to keep track of the database's status and physical structure. Every Oracle Database must have at least one control file. However, it is recommended to create more than one. Each copy of a control file should be stored on a different disk drive. One practice is to store a control file copy on every disk drive that stores members of online redo log groups, if the online redo log is multiplexed. By storing control files in these locations, customers minimize the risk that all control files will be lost in a single disk failure. The control file contains information like: Database name Timestamp of database creation Names and locations of data files Names and locations of redo log files The current log sequence number 14

15 Checkpoint information Recent RMAN backups taken Etc Data Files Default location: Oracle_Base\oradata\SID\*.dbf Data files are used to store data, including user data and undo data. Data files are grouped together into table spaces. They can be stored in a file system or inside ASM Redo log files Default location: Oracle_Base\ORADATA\SID\*.log Redo log files save database changes on disk before the commit is returned to the application. When a transaction is committed, the transaction's details in the redo log buffer is written to a redo log file. When protecting redo log files, it's important to remember that customers can specify multiple locations for them for better protection and performance, like in a dedicated virtual disk or a storage volume. For these reasons, a backup administrator should check with the database administrator to obtain all the existing locations of these files Archive log files Default position: none, specified at activation Archive log files are additional copies of redo logs created at each log rotation. They offer a separated retention from redo logs and are important for point-in-time restores. 15

16 5. Data protection scenarios In this chapter, we will focus on a number of common data protection and related restore procedures. Your specific scenario could be different, but in this case, use the described scenarios as a general guideline. 5.1 Backup of the entire Windows VM When Oracle is installed and running on a Windows guest OS, a Veeam administrator can leverage VSS libraries to offer application consistency of the Oracle database(s), and to protect the entire VM at the same time. The configuration of the Veeam backup or replication job is similar to other scenario where VSS is involved (figure 5). Figure 5 By selecting the option "Enable application-aware processing," VSS is automatically invoked during the backup, and as long as the Oracle VSS Writer is correctly registered and available in the Oracle Windows VM, VSS will be used to properly freeze the database and database files and place the database itself in an application-consistent state. You can verify the state of the Oracle VSS by running from a command line: VSSADMIN LIST WRITERS By default, Oracle installs one VSS writer for each database, so in some situations you could find more than one writer. 16

17 The main advantage of this method is its simplicity. No scripting is required, and with a simple configuration in the Veeam job, proper application consistency is guaranteed. During restores, this method is useful for different restore options: Replication: The entire VM and its Oracle database are properly replicated in a secondary VM. When needed, the replicated VM is ready to be powered on and proceed to failover. Instant VM Recovery : If a complete restore of the VM is needed, the VM and its Oracle database are in a consistent state and the restore from the backup copy of the VM itself can be immediately started. Database restore: Veeam Instant File-Level Recovery (IFLR) can be used to restore single files of the Oracle VM, either the database files or any of the important files listed in Chapter 4.2. During the restore phase, there could be two possible situations, based on the presence of the archive logs. If archive logs are not available (or were not configured), the restore is only possible to the point in time when the backup itself was created. Instead, if archive logs have been configured and they have been saved together with the entire VM (or in another location that is available during the restore operation), point-in-time restores are possible. When restarted (or restored), an Oracle database goes directly into ONLINE mode, and because of this, archive logs cannot be used. To use them, first you will need to start the Windows VM is Safe Mode, in order to avoid the auto-start of the Oracle services. When started, you can change the start type of any Oracle related services to manual, and restart the VM in regular mode. Once started, you can manually start the Oracle database in MOUNT mode, and use the archive logs to restore the database to the desired point in time. 17

18 5.2 Database consistency by scripts When Oracle is installed and running on an operating system with no VSS support, like Linux, you can guarantee database consistency using scripts. There are two distinct phases in this scenario the preparation and the protection. During the preparation phase, you need to verify that all the requirements are fulfilled in order to guarantee a successful backup. The following scenario requires Oracle 10g or newer; scenarios with older versions are supported but not described in this paper. First of all, in the Oracle VM, you need to verify that you can start the command sqlplus from any location in the file system. If not, you need to add the location of the command to the system path. Then, you should verify you can login into each available instance with a command like: sqlplus /@YOURINSTANCENAME as sysdba If this is not possible, you need to interact with your Oracle Administrator to obtain a login to use. While working with your Oracle Administrator, also check the complete list of existing instances. You must be able to login and run scripts on each of them. Then, if you want to use scripts in a Windows VM instead of the VSS libraries, you must disable all Oracle VSS services. On the Veeam Backup Server, we recommend to install Veeam Backup & Replication v8 Patch 1 (build ) or newer. With it, you can use Veeam InGuest Scripting. If you are using instead a previous version of Veeam, you can use VMware Tools quiescence. Once the environment is ready, you can move to the execution phase. The method that will be used is based on the "Alter Database" commands. This series of commands tell Oracle to commit logs into the data files so that they are consistent. The commands needed to place the Database in a consistent state are: ALTER DATABASE BEGIN BACKUP; ALTER DATABASE BACKUP CONTROLFILE TO file-name; ALTER SYSTEM ARCHIVE LOG CURRENT; While at the end of the backup activity, you need to execute: ALTER DATABASE END BACKUP; ALTER SYSTEM ARCHIVE LOG CURRENT; As explained before, there could be two different situations based on the version of Veeam Backup & Replication you are using. Let's see both of them. If you run these scripts on a Windows machine, you need to disable the Oracle VSS Service to avoid any conflicts at the InGuest processing. 18

19 5.2.1 Veeam Backup & Replication v8 Patch 1 With Veeam Backup & Replication v8 Patch 1, you can store the scripts directly in the Veeam Backup Server itself, and they will be executed during the backup operation into the Oracle VM. You start by creating a Windows shell script: c:\scripts\beforebackup.bat Supposing the Oracle instance is called ORCL, the content of the script will be: sqlplus /@ORCL as As you can see, the shell script calls a second script, this time in SQL format. The content of this second script will be: ALTER DATABASE BEGIN BACKUP; ALTER SYSTEM ARCHIVE LOG CURRENT; EXIT; These scripts will be executed as a pre-job activity. After the backup activity will be completed, a new script will be executed as a post-job activity. Again, the first script will be a shell script: c:\scripts\afterbackup.bat And its content will be: sqlplus /@ORCL as The content of the SQL script, as explained, will be: ALTER DATABASE END BACKUP; ALTER SYSTEM ARCHIVE LOG CURRENT; EXIT; 19

20 Once all the scripts have been created, you will need to configure the backup job to use them. To do so, in the Guest Processing part of the job configuration, you will have to change the "Application-Aware Processing Options" and set the Scripts, like in this screenshot (figure 6). Figure 6 NOTE: If the Oracle VM is running Linux, scripts will need to be.sh 20

21 5.2.2 Veeam Backup & Replication v8 or v7 With previous versions of Veeam Backup & Replication, script will need to be placed directly into the Oracle VM, and invoked using VMware pre-freeze and post-thaw options. On the Oracle VM, you will need to create three scripts. This example is again for a Windows OS, soif you are running Oracle on a Linux OS, change the extension of the first script to.sh and place all of them in the appropriate path. Also, modify the paths listed in the script itself. C:\Program Files\VMware\VMware off if "%1%" == "" if "%1%" == "freeze" if "%1%" == "thaw" goto noparam goto dofreeze goto dothaw if "%1%" == "freezefail" goto dofreezefail goto wrongparam :dofreeze sqlplus /@orcl as goto End :dothaw sqlplus /@orcl as goto End :dofreezefail sqlplus /@orcl as goto End :noparam goto End :wrongparam goto End :End 21

22 c:\scripts\beforebackup.sql ALTER DATABASE BEGIN BACKUP; ALTER SYSTEM ARCHIVE LOG CURRENT; EXIT; c:\scripts\afterbackup.sql ALTER DATABASE END BACKUP; ALTER SYSTEM ARCHIVE LOG CURRENT; EXIT; As you can see, the SQL commands are the same as before. If possible, we suggest you upgrade your Veeam Backup & Replication installation to v8 Patch 1. The option to directly store all the needed scripts in the Veeam Backup Server itself is a great additional value, since you do not have to connect to each protected VM and store scripts there; Veeam will dynamically copy the needed scripts into the VMs, execute them, and delete them at the end of the backup job. 5.3 Data protection with RMAN As described in Chapter 3.4, RMAN (Recovery Manager) is the native Oracle tool for database protection, backup and recovery. RMAN is commonly used and well accepted by Oracle DBAs, Oracle support and many applications using Oracle as a backend database. It has interesting features like the ability to backup only used blocks, and the capability to automatically verify backup consistency. RMAN uses another Oracle database for its configuration and its catalog. This is usually stored on a separated Oracle Server from the one RMAN is protecting. The integration between Veeam and RMAN can happen in two different ways. Veeam protecting RMAN backups RMAN can use for its activities different storage options. Some of these solutions can be protected by Veeam, so that any content stored by RMAN can be saved in a secondary location by Veeam. The local storage where RMAN itself is running: For additional protection and a significant reduction of the failure domain, RMAN is usually executed on a different machine than the Oracle Server that RMAN is protecting. If the RMAN server is a VM, Veeam can protect RMAN and store its data by protecting the entire RMAN VM. A network share: In this case, again, Veeam can protect RMAN if the share is exposed by a VM. During a restore operation, Veeam users can leverage Instant VM Recovery to restore the entire VM used as RMAN target (or even the RMAN machine itself as in the first scenario) in few minutes. In this way, RMAN can access its stored data from the target machine and initiate any restore activity. 22

23 Another option is to use Veeam U-AIR (Universal Application-Item Recovery) to restore the VM in an isolated environment, so both the restored VM and its production version can be up and running at the same time; then users can restore from the restored VM directly into the target machine any needed RMAN backup files. Both solutions offer a quick and effective way to protect RMAN data and a fast way to restore data when needed Veeam integration with RMAN scripts Veeam Backup & Replication can invoke RMAN via scripts to protect Oracle databases in scenarios where RMAN support is preferred by the customer, or when RMAN is the supported method for data protection, like RAC clusters. As explained in Chapter 5.2, scripts can be easily stored directly into Veeam Backup & Replication starting with version 8 Patch 1, or into the RMAN machine in previous versions. In both cases, Veeam will invoke the scripts, and the scripts will be executed using proper RMAN syntax. The final result will be proper RMAN activities initiated by Veeam. A complete description on all the possible activities with RMAN is out of the scope of this document, however we want to offer some examples for the most common operations. Enable archive logs Archive logs are a mandatory prerequisite for RMAN. Since they are not enabled by default in an Oracle installation, it's useful to know how to enable them as a first step in any RMAN scenario. These commands are not specific to RMAN. sqlplus / as sysdba SQL> shutdown immediate; SQL> startup mount; SQL> ALTER DATABASE ARCHIVELOG; SQL> alter system set log_archive_dest:_1= LOCATION=l:\archlog1 scope=both; SQL> alter system set log_archive_dest:_2= LOCATION=m:\archlog2 scope=both; SQL> select dest_name,status,destination from V$ARCHIVE_DEST; SQL> ALTER DATABASE OPEN; As you see from the example, you can have multiple locations for archive logs, for high availability purposes. Each line describes an additional location that can be configured. 23

24 ControlFile Autobackup The Control File (see Chapter 4.2.3) is small in size, and it s needed in many restore scenarios. RMAN usually saves all the database files, while the Control File is saved only under certain conditions: There has been a config change (like adding tablespaces or adding data files) At first backup run If AUTOBACKUP is configured In Oracle, you can enable the automatic backup of the Control File during each backup run by enabling autobackup: SQL> configure controlfile autobackup on; Start RMAN with external catalog database This is a typical command to start RMAN connected to a catalog database: rman TARGET sys/password@orcl CATALOG rmanuser/password@catdb The command has some specific parameters. In a given scenario, these values needs to be replaced with proper values: TARGET is the Oracle server that needs to be protected CATALOG is the catalog service name sys is the the local admin of the Oracle database that needs to be protected rmanuser is the admin user of the catalog database CATDB is the service name which links to the external catalog database Retention for databases and archive logs Within RMAN, you can configure the desired retention period with a simple command: rman TARGET sys/password@orcl CATALOG rmanuser/password@catdb RMAN>CONFIGURE RETENTION POLICY TO RECOVERY WINDOW OF 7 DAYS; Be careful with this setting. After the retention period is reached, archive logs older than seven days will be deleted from the database server, and the only copy will be available in RMAN. This is useful to prune archive logs, but this configuration needs to be discussed and approved by the Oracle DBAs. 24

25 RMAN backup example In this example, RMAN will use an SMB share as a target, and save its backup sets there. The sets will be split into chunks of 1GB each (maxpiecesize 1000 M). The command will save all the databases, and every archive log that hasn't been saved yet. Cross-check updates the RMAN repository, and ensures that data about backups in the recovery catalog or Control File is synchronized with corresponding data on disk or in the media management catalog. Finally, the delete commands delete the backups which are older than the retention policy set. rman TARGET sys/password@orcl CATALOG rman/password@catdb RMAN>run { allocate channel Channel1 type disk format '\\ \RMAN\ ORACLEWIN-ORCL_b_%u_%p_%c_%D_%M_%Y' MAXPIECESIZE 1000 M ; backup AS COMPRESSED BACKUPSET database; backup AS COMPRESSED BACKUPSET archivelog all not backed up 1 times; CROSSCHECK BACKUPSET; DELETE NOPROMPT OBSOLETE; DELETE NOPROMPT EXPIRED BACKUP;} LIST BACKUP SUMMARY; For additional configuration options, see the Oracle documentation. 25

26 5.4 Restore examples We are going to describe two common scenarios in this chapter. Use the example as a baseline for specific scenario, or engage your Oracle DBA to complete more complex restores Restore from backups using scripts In this scenario, there is a VM holding an Oracle database. The database has a single instance, and was protected using scripts for consistency. Both the copy of the VM (containing the database files) and the archive logs are stored in a secondary location. Following a complete loss of the VM, we want to restore the Oracle database to the latest available restore point, which corresponds to the latest SCN stored in the latest saved Archive Log. First, we restore the entire virtual machine, and we start it. By using Veeam Instant VM Recovery, this operation can be really quick. The database is still in backup mode since the pre-job script set the database in this state with the command: ALTER DATABASE BEGIN BACKUP; We do not open the database yet after the restore. Instead, we shutdown the instance: sqlplus / as sysdba SQL>SHUTDOWN IMMEDIATE; If there are newer archive logs than those stored in the VM, maybe because a dedicated job is saving archive logs with a higher frequency in a different location, we restore all of them in the original position. At this point, we mount the database without still opening it: SQL>STARTUP MOUNT; We read the archive logs and we look for the last known archive log SCN: SQL>select * from V$LOG_HISTORY; Check for the last entry. Read the Next_Change# entry and reduce it by one. For example, if NEXT_ CHANGE is then use in the next command. Finally, we recover the database to the last change of the archive logs and we clean the redo logs: SQL>RECOVER AUTOMATIC DATABASE UNTIL CHANGE ; SQL>ALTER DATABASE OPEN RESETLOGS; 26

27 5.4.2 Restore from RMAN In this scenario, there is a VM holding an Oracle database. The database has a single instance, and was protected using RMAN. Following a complete loss of the VM, we want to restore the Oracle database to the latest available restore point, which corresponds to the latest SCN stored in the latest saved archive log. First, we restore the entire VM, and we start it. By using Veeam Instant VM Recovery, this operation can be really quick. Then, we immediately use RMAN for the restore of the database to a desired point in time, identified as in the previous example by an SCN value: rman TARGET sys/password@orcl CATALOG rman/password@catdb RMAN>LIST BACKUP SUMMARY; RMAN>RUN { allocate channel Channel1 type disk format \\ \RMAN\ ORACLEWIN-ORCL_b_%u_%p_%c_%D_%M_%Y' MAXPIECESIZE 1000 M ; SET UNTIL SCN ; RESTORE DATABASE; RECOVER DATABASE; } 27

28 About the Author Luca Dell Oca is EMEA Evangelist for Veeam Software. Based in Italy, Luca is a popular blogger and an active member of the virtualization community. Luca s career started in information security before focusing on virtualization. His main areas of expertise are VMware and storage, with a deep focus on Service Providers and Large Enterprises. He holds VCAP-DCD and CISSP certifications, and is a VMware vexpert since Also, Luca is Veeam VMCE #1. Follow Luca on About Veeam Software Veeam recognizes the new challenges companies across the globe face in enabling the Always- On Business, a business that must operate 24/7/365. To address this, Veeam has pioneered a new market of Availability for the Modern Data Center by helping organizations meet recovery time and point objectives (RTPO ) of less than 15 minutes for all applications and data, through a fundamentally new kind of solution that delivers high-speed recovery, data loss avoidance, verified protection, leveraged data and complete visibility. Veeam Availability Suite, which includes Veeam Backup & Replication, leverages virtualization, storage, and cloud technologies that enable the modern data center to help organizations save time, mitigate risks, and dramatically reduce capital and operational costs. Founded in 2006, Veeam currently has 29,000 ProPartners and more than 135,000 customers worldwide. Veeam s global headquarters are located in Baar, Switzerland, and the company has offices throughout the world. To learn more, visit 28

29 29