|RmanJ is a feature-rich
Java-based control utility for Oracle Recovery
Manager (RMAN). It works with both Oracle Database
Standard Edition (SE) and Oracle Database
Enterprise Edition (EE). RmanJ is a general
purpose control utility for RMAN-based copy,
backup, recover, and restore operations – in fact
it is capable of dispatching all the commands that
RMAN supports. RmanJ excels when used to enable
parallel copy, backup, and restore operations with
Oracle Database Standard Edition thus allowing
RMAN-based operations to complete orders of
magnitude faster than serial operations offered by
Oracle RMAN in a Standard Edition environment.
Moreover RmanJ includes a comprehensive set of
locking, monitoring and reporting features rarely,
if ever, found in backup scripts that invoke
Oracle RMAN. Typically each company or site that
operates Oracle RDBMS instances codes its own
control script for Oracle RMAN. Over the years the
creators of RmanJ have encountered many such
scripts at customer sites with significant numbers
of those scripts exhibiting shortcomings such as:
Failure to check the return code from RMAN.
Highly sensitive passwords such as the password
for the omnipotent user SYS stored in clear text
either in the backup script itself or in a
No locking to prevent concurrent execution of the
same or similar copy or backup operation.
No notification of backup failures via e-mail.
Backup performed after connecting to an RMAN
backup catalog which makes the backup fail should
the catalog become unavailable.
All the shortcomings mentioned above are addressed
and resolved by RmanJ. However RmanJ doesn't stop
there. It includes many more useful features and
removes the burden of coding and maintaining a
company or site-specific backup script.
Furthermore RmanJ's password encryption may be
leveraged to safely centralize all backup
operations on a single system and by controlling
backup (or restore) operations on all RDBMS
instances in the network over TCP/IP. It is
recommended to use the new SYSBACKUP user account
in Oracle12c for this purpose since it has less
privileges than SYS, e.g. it cannot SELECT from
any table with customer data.
Parallel Operations in an Oracle Standard
Any RMAN-based copy, backup, or restore operation
requires a so-called channel to transfer data
between a database file and an RMAN backup piece
(i. e. part of a larger backup) and vice versa.
While Oracle EE places no practical restriction on
the number of parallel channels used by a single
invocation of RMAN1, Oracle SE does not allow
parallel use of channels per RMAN invocation at
all. Hence RMAN operations in an Oracle SE
environment cannot leverage the speed of today's
CPUs as well as the data transfer bandwidths of
today's disk storage subsystems. RmanJ overcomes
the single channel limitation of Oracle SE by
controlling many invocations of RMAN in parallel
using Java's support for multithreading. Load
balancing across many invocations of RMAN occurs
at the data file level. All the data files
involved in an RMAN operation are enqueued into a
thread-safe queue. Multiple threads then dispatch
individual data files to available RMAN
invocations. Whenever an RMAN invocation finishes
handling one of the data files it signals
completion using the message code RMAN-03091. The
message is received by one of RmanJ's threads
which then hands off the next data file to RMAN
until all data files have been processed. Note
that RMAN invocations are reused to optimize
performance and to avoid the overhead of starting
and stopping RMAN processes.
Speedup in a Standard Edition Environment
Since the restriction of a single RMAN channel
does not apply when backing up or restoring with
RmanJ in an Oracle Standard Edition environment,
these operations complete orders of magnitude
faster than without RmanJ. RmanJ utilizes the high
speed of today's multi-core CPUs and fast disk
interfaces to reduce backup and restore times to
one 8th or even less of a serial backup. Of course
results vary with the capability of the hardware.
Backup compression is likely to lead to a further
increase in speed since it reduces I/O bandwidth
requirements. Normally RMAN compression results in
a reduction of the backup size to approximately
one 3rd of the uncompressed size. Backups to and
restores from disk tend to benefit more from
parallelization due to the random access
characteristics of disk drives. Parallel backup to
tape using RMAN requires a so called media
managment library that is usually an extra cost
product from the backup software vendor. Each
physical tape drive also imposes an extra cost.
Thus RMAN backups to more than two phyiscal tape
drives in parallel are almost never seen in the
field. Use of a virtual tape library is
recommended for highly parallelized backups with
RmanJ. Sufficient network bandwidth is required
when NFS volumes are used for backup storage.
Several examples of speedups attained on actual
customer systems are reproduced below.
Whole Database Backup (Incremental Level 0
The timings given below are for
the execution time of the entire backup script
including archived log backup and removal of
obsolete backup pieces that both run serially.
Software used: Oracle Standard Edition,
- Serial backup without RmanJ:
6 hours, 47 minutes, 23 seconds.
- Parallel backup with RmanJ,
parallel degree 8: 59 minutes, 36 seconds.
The elapsed time for the
parallel backup was reduced to merely 14.6% of
the elapsed time of the serial backup. The
speedup for the entire process was nearly
linear even though it involves several steps
that are not parallelized.
Incremental Backup (Incremental
Level 1 with Compression)
Timings again include serial execution steps as
above. Note that Oracle Standard Edition used
for the test does not have block change tracking
and thus much slower incremental level 1 backup
than Enterprise Edition.
backup without RmanJ: 1 hour, 11
- Parallel backup with RmanJ,
parallel degree 8: 21 minutes, 49 seconds.
elapsed time for the incremental backup was
reduced to 30% of the serial execution time.
Restore throughput was gauged based on
restoring data files and averaged over a period
of 10-20 minutes. The results given are for
restoring from compressed backup pieces (one
backup piece per data file) from an NFS volume.
The throughput figures are based solely on the
data file size and ignore the additional I/O
bandwidth consumed to read the compressed backup
pieces (in other words total throughput is
higher). Direct NFS was enabled within the
Oracle home on Linux x86-64 (NFS mount performed
- Serial restore throughput without RmanJ:
- Parallel restore throughput with RmanJ,
parallel degree 8: 199.8
- Parallel restore throughput with RmanJ,
parallel degree 16: 351.1
Based on the results above it would take 14
hours and 18 minutes to restore the customer's
1.243 TB database with Oracle Standard Edition
(serially). With RmanJ and a parallel restore
with degree 16 restore time is reduced to just 1
hour, 1 minute, and 52 seconds for a reduction
of more than 13 hours. Needless to say that the
time savings are highly significant in the event
of an unplanned outage of a production system.
The following is a list of the most prominent
features of RmanJ.
To learn about all aspects and features of RmanJ
please consult the RmanJ
User Guide in PDF format.
- Parallel copy, backup, duplicate, and
restore operations for Oracle Standard Edition
- Password encryption for all users (target,
auxiliary, and RMAN catalog databases)
- Support for the SYSBACKUP privilege
introduced in Oracle 12c
- Notification via e-mail
- Parser for RMAN output that recognizes RMAN
error stacks and maintains a counter of
- Support for archived log shipping and
immediate or delayed archive log apply to a
standby database in non Enterprise Edition
environments where Oracle Data Guard is not
For further information and to request a quote or
trial license please contact us by phone or e-mail