Veeam Backup & Replication v8: Availability for Oracle ...v2.itweb.co.za/whitepaper/Whitepaper_Veeam_Backup_Replication_v… · 5.3.1 Veeam integration with RMAN scripts..... 23 Enable

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

Veeam Backup & Replication v8: Availability for Oracle Environments

2© 2015 Veeam Software

Contents1. Executive summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.1 Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2.2 Purpose. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3. Oracle overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.3 Oracle architecture overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

3.1.1 How a write happens in Oracle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .7

3.1.2 Data consistency via SCN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .8

3.1.3 Redo logs and archive logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9

3.2 Main Oracle deployment types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.2.1 RAC and SCN consistency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3 ASM (Automatic Storage Management) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.4 RMAN (Recovery Manager) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

4. Oracle Data Protection overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.1 Data protection scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

4.2 Which components to protect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.1 alert.log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.2 Parameter file. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.3 Control File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4.2.4 Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.5 Redo log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

4.2.6 Archive log files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15



5. Data protection scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.1 Backup of the entire Windows VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

5.2 Database consistency by scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18

5.2.1 Veeam Backup & Replication v8 Patch 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

5.2.2 Veeam Backup & Replication v8 or v7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.3 Data protection with RMAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

Veeam protecting RMAN backups . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

5.3.1 Veeam integration with RMAN scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Enable archive logs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

ControlFile Autobackup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

Start RMAN with external catalog database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

RMAN backup example. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

5.4 Restore examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4.1 Restore from backups using scripts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

5.4.2 Restore from RMAN. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

About the Author . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

About Veeam Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28



1. Executive summaryVirtualized 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.



2. Introduction2.1 AudienceThis 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 v8.

2.2 PurposeThis 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.



3. Oracle overviewOracle 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 overviewFor 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



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.

3.1.1 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.



The activity flow can be represented like in this diagram (figure 2).

Figure 2

3.1.2 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.



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 1376995.1. 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 12371955); you are invited to apply

it, or to use "alter tablespace" if you cannot apply the patch for any reason.

3.1.3 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.



Archive logs are not configured by default in Oracle. Once they are enabled, they allow for point-in-

time 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 typesBased 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.



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.



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.



4. Oracle Data Protection overviewIn 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 scenariosTwo 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



4.2 Which components to protectRegardless 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.

4.2.1 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.

4.2.2 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.

4.2.3 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



• Checkpoint information

• Recent RMAN backups taken

• Etc.

4.2.4 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.

4.2.5 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.

4.2.6 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.



5. Data protection scenariosIn 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 VMWhen 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.



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.



5.2 Database consistency by scriptsWhen 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

8.0.0.971) 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;


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.



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 sysdba @c:\scripts\beforebackup.sql

As you can see, the shell script calls a second script, this time in SQL format. The content of this second

script will be:



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 sysdba @c:\scripts\afterbackup.sql

The content of the SQL script, as explained, will be:



EXIT;



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



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 Tools\backupScripts.d\oracle.bat

@echo off

if "%1%" == "" goto noParam

if "%1%" == "freeze" goto doFreeze

if "%1%" == "thaw" goto dothaw

if "%1%" == "freezeFail" goto dofreezefail

goto wrongParam

:doFreeze

sqlplus /@orcl as sysdba @C:\scripts\beforebackup.sql

goto End

:dothaw

sqlplus /@orcl as sysdba @c:\scripts\afterbackup.sql

goto End

:dofreezefail

sqlplus /@orcl as sysdba @c:\scripts\afterbackup.sql

goto End

:noParam

goto End

:wrongParam

goto End

:End



c:\scripts\beforebackup.sql



EXIT;

c:\scripts\afterbackup.sql



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 RMANAs 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.



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.

5.3.1 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.



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.



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 '\\10.254.49.91\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.



5.4 Restore examplesWe 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.

5.4.1 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:


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 1420424 then use 1420423 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 1420423;

SQL>ALTER DATABASE OPEN RESETLOGS;



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 ‘\\10.254.49.91\RMAN\

ORACLEWIN-ORCL_b_%u_%p_%c_%D_%M_%Y' MAXPIECESIZE 1000 M ;

SET UNTIL SCN 1323261;

RESTORE DATABASE;

RECOVER DATABASE;

}



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 2011. Also, Luca is Veeam VMCE #1.

Follow Luca on Twitter @dellock6 or @veeam.

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 http://www.veeam.com.

About the Author

https://twitter.com/dellock6

https://twitter.com/veeam

http://www.veeam.com/?ad=pr

http://www.veeam.com/data-center-availability-suite.html?ad=pr

http://www.veeam.com/vm-backup-recovery-replication-software.html

http://www.veeam.com



Documents

Veeam Backup & Replication v8: Availability for Oracle ...v2.itweb.co.za/whitepaper/Whitepaper_Veeam_Backup_Replication_v… · 5.3.1 Veeam integration with RMAN scripts..... 23 Enable