Veeam Data Protection Oracle Environments

Veeam Backup
& Replication v8:

Availability for Oracle
Environments
Luca DellOca
EMEA Evangelist at Veeam ,vExpert, VCAP-DCD, CISSP
Veeam Backup & Replication v8: Availability for Oracle Environments
Contents
1. 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
2015 Veeam Software 2

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 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 reductionits 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. Introduction
2.1 Audience
This document is intended for use by individuals working in companies using Oracle databases in
virtualized environments. Regardless of rolesdatabase administrators, virtualization specialists,
storage or network managers, or data protection adminsthis 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 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.

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

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. T he 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. T he 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. D
atabase Writer (DBWR) permanently processes data and modifies the relevant data blocks in the
database file.
9. W
hen 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:
E very 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.
E very 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.
R
ead 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 its 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 simpleat 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.

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, its 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
users 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 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

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

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:
R
eplication: 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.
D
atabase 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 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 scenariothe 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 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.

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 its 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 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.
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;

About the Author

Luca DellOca is EMEA Evangelist for Veeam Software. Based in Italy, Luca is
a popular blogger and an active member of the virtualization community.
Lucas 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. Veeams global headquarters are located in Baar, Switzerland, and the company has
offices throughout the world. To learn more, visit http://www.veeam.com.


Veeam Data Protection Oracle Environments

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Veeam Data Protection Oracle Environments

Загружено:

Авторское право:

Доступные форматы

Veeam Backup

& Replication v8:

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

2015 Veeam Software 2

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

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

2015 Veeam Software 3

2015 Veeam Software 4

2015 Veeam Software 5

3.3 Oracle architecture overview

2015 Veeam Software 6

3.1.1 How a write happens in Oracle

1. The application connects to the Oracle instance.

2015 Veeam Software 7

3.1.2 Data consistency via SCN

In database technologies, a single logical operation on the data is called a transaction.

2015 Veeam Software 8

(maximum value of wrap * 4 billion = 65536* 4* (2^30) = 281,474,976,710,656 = 281 trillion)

3.1.3 Redo logs and archive logs

2015 Veeam Software 9

3.2 Main Oracle deployment types

Single Instance: one instance accessing a given database

2015 Veeam Software 10

3.2.1 RAC and SCN consistency

3.3 ASM (Automatic Storage Management)

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

Normal for 2-way mirroring

High for 3-way mirroring

2015 Veeam Software 11

3.4 RMAN (Recovery Manager)

RMAN has different components, some mandatory: