Zero Data Loss Recovery Appliance - Deep Dive

Zero Data Loss Recovery Appliance - Deep Dive

1. BASLE BERN BRUGG DÜSSELDORF FRANKFURT A.M. FREIBURG I.BR. GENEVA
HAMBURG COPENHAGEN LAUSANNE MUNICH STUTTGART VIENNA ZURICH ZDLRA –DeepDive
Daniele Massimi –PrincipalConsultant
BE-IMS

2. Agenda
ZDLRA -in Action2 21.06.2017
1.ZDLRA –Functionalityunderthehood
2.Installation and Configuration from bottom up
3.Have a lookinside–(just particularities)
4.From protected Databases to backups
5.Backup and RecoveryCapabilities
6.Recovery Appliance Views and Utilities
7.Conclusion

3. Who am I
ZDLRA -in Action3 21.06.2017
Daniele Massimi, TrivadisAG (CH, Bern)
Principal Consultant [email protected]
Seit 2012 beiTrivadisIMS (Infrastructure Service Management)
Oracle DBA seit2000 (Exadata > 6 Jahre)
Infrastruktur -Architekturen, Operations & Administration, Upgrades and Migration,
High Availability, Backup & Recovery, Virtualizierung
Engineered Systems (Exadata, ODA, ZDLRA, PCA)
Trainer (Oracle Architecturand Internal, 12c New Features, Exadata)
Oracle Certifications
Oracle Certified Master (11g)
Oracle Certified Professional (8i –12c)
Oracle Certified Expert (RAC)
Oracle Implementation Specialist (Exadata, OVM)

4. Our company.
© Trivadis –The Company4 21.06.2017
Trivadisisa marketleaderin IT consulting, systemintegration, solutionengineering
andtheprovisionofIT servicesfocusingon and
technologies
in Switzerland, Germany, Austria andDenmark. Weofferourservicesin thefollowing
strategicbusinessfields:
TrivadisServices takesovertheinteractiveoperationofyourIT systems.
O P E R A T I O N

5. ZDLRA -in Action5 21.06.2017
ZDLRA
FunctionalityundertheHood

6. Common problemswithOracle backups
ZDLRA -in Action6 21.06.2017
RPO dependson archive backup frequency(manyminutes or hours)
Backup windowand nightlybatchescompetefor resources
High network bandwidthusage for full backups
Low -speed backups and restores
Backup and restore successratio penalizedby sharedinfrastructure
Critical databasesrequireData Guardfor transaction safety
–Additionalstoragespace, licenseand computation required
Expiration of backup set on ML: needto crosscheckand deleteexpired
Lack of backup validation
…

7. RecoveryAppliance Architecture
ZDLRA -in Action7 21.06.2017
Source: Oracle

8. Minimal Backup Overhead
8 21.06.2017
Traditional Backup
–Read/Write forDisk/Tape Backup
–Deduplication
–Compression
–Validation
–Deletion
–Merging
All on databasehost
Degradeperformance
Recovery Appliance
–Offloadingoperations
–Delta Push
–Delta Store
Source: Oracle

9. Delta Push
ZDLRA -in Action9 21.06.2017
Delta Push is a highly optimized form of source -
side optimization
–Through RMAN block change tracking
–Noreadingofunchangeddata
Two operationson theprotectedDatabase
–Incremental"forever" backup
–Real time redotransport
One -time full backup as prerequirement
Afterwards Incremental forever backup
Validate incoming Backups against corrupted
physicalblocks
Compress the Backups using special block -level
Algorithm
BackupedDatabase
Changed Data
Less data, less I/O, less network traffic
Source: Oracle

10. Eliminate data loss –Real Time redo transport
ZDLRA -in Action1021.06.2017
Real Time redotransport
–Data Guardlike but asynchronous
–Changesout ofLogbuffertransfered
–Validateandwritestoa stagearea
Redolog switchon database
–RA convertsthestagedredodatatoa
compressedarchivedredologbackup
–Writesthisarchlogbackuptocatalog
–Readyforfuturerestores
Explicit Archivelogbackupnomorenecessary
ReducesRPO to(near) zero
Source: Oracle

11. Delta Store –the “brains” of the Recovery Appliance
ZDLRA -in Action1121.06.2017
Backup
Totality ofall Database Backup in a
Storage Location
validates the incoming blocks
compresses, indexes and stores
deduplicate , lessstorageusage
High numberofvirtualfullbackups
Higher recoverwindow
Delta Store
Day N
Incr
Day 1 Virtual Full
Day N Virtual Full
Day 1
Incr
Day 0
Full
Source: Oracle

12. Delta Store –efficient restore/recover
ZDLRA -in Action1221.06.2017
Restore
Creates a Virtual Full Database
Backups
No needoftransferand apply
incrementalbackupsduringrestore
operations
Roll forwardwithrestoredredologs
Uses Exadataperformanceand
scalability
Delta Store
Day 0
Full
Day 1
Incr
Day N
Incr
Day ‘N’ Full Backup
Source: Oracle

13. Delta Pools
ZDLRA -in Action1321.06.2017
Chunks inside the Delta Store
Backups will be indexed and stored inside the Delta Pools
Set of datafiles blocks from which RA constucts Virtual Full Backups
Each backuped datafilewill havehis own delta Pool
Automated delta pool space management
–ProtectionPolicywill beinheritedtodatabaseretentionpolicy
–Delete automatically expired or obseleted Backups
–Periodically reorganising for performance improving
–Delta pool optimization when old blocks are deleted and new incremental Backup
arriving
Source: Oracle

14. Delta Push –howitworks(1/2)
ZDLRA -in Action1421.06.2017
Clients addresstheHTTP Servlet on ZDLRA
RMAN shipsincrementalBackup toStagingArea
Data will bevalidatedandMetadatawill bestoredon RAC Database
Data Blocks ofBackupsets will beindexedandstoredon Delta Store
Source: Oracle

15. Delta Push –howitworks(2/2)
ZDLRA -in Action1521.06.2017
Optionally Real Time RedoTransport couldbeactivated
ZDLRA will beusingData GuardTechnology (RFS on RA)
Validated RedoBlocks will bestoredon Delta Store
Archive Logs will begeneratedwhenevera Log Switch happen on ProdDB
Optionally youcanreplicateorcopytoa remote ZDLRA orTape
Source: Oracle

16. Restore –howitworks
ZDLRA -in Action1621.06.2017
Clients addresstheHTTP Servlet on ZDLRA
ZDLRA re-assembleandvalidate"virtual Backupsets"
Data Blocks will beshippedback toClient
Source: Oracle

17. Policy-Based Database Protection as a Service
ZDLRA Workshop -Introduction1721.06.2017
Standardized
protectionpolicies
–Recoverywindow
–Retention
–Replication
Gold Policy –Customer Critical
Disk: 45 days
Tape: 90 days
Silver Policy –Internal Critical
Disk: 30 days
Tape: 45 days
Bronze Policy -Test/Dev
Disk: 15 days
Tape: 30 days

18. Protection PoliciesAttributes
ZDLRA Workshop -Protection Policies1821.06.2017
Storage Location Recovery Appliance storage location for storing backups
Recovery Window Disk Tape recovery window goal for the protected database
Recovery Window Tape Tape recovery window goal for the protected database
Max Retention Policy maximum length of time that the Recovery Appliance retains
backups for databases that use this retention policy
Guaranteed Copy guaranteed copy setting, which determines whether backups
protected by this policy must be copied to tape or replicated before being considered
for deletion
Polling Policy optional backup polling policy that determines whether Recovery
Appliance polls a storage location for backups or deletion
Unprotected Window maximum acceptable difference between the current time
and the latest time that the database can be restored

19. RecoveryWindow–Index Efficiency (1/2)
ZDLRA -in Action1921.06.2017
Only newversionofData Blocks will bebackedup(inclevel1)
Recovery windowscontrolsdeletionpolicyoftheblocks
Main scopeistomaintaintherestorabilitywithintherecoverywindows
Old andnomoreneededblockswill bedeleted
If enoughspaceisavailabletheRecoveryWindows canbeoverachieved
Source: Oracle

20. RecoveryWindow–Index Efficiency (2/2)
ZDLRA -in Action2021.06.2017
Once theoldblockswas deleted, wewill havea defragmentationwithinthe
storage
This situationwill providerandomI/O insteadofsequentialI/O Performance
degradation
Intermittently theRA will automaticallyreorganizetheblocks
Implicitly all touchedblockswill bephisicalandlogicalcheckedon hisintegrity
Source: Oracle

21. Storage Locations
ZDLRA -in Action2121.06.2017
Main Storage Location aretheContainer withintheASM Diskgroup
It ispossibletohavemorethanoneStorage Location in ASM
Backup Polling Locations areStorage Location outside fromZDLRA (e.g. NFS Mount)
•Backups areplaceddirectlytothislocationwithoutinteractingwithZDLRA
•WithPolling Policiesyoucandefinehowoftenandwhere
isthepollingdirectory
•Onceall requirementmeetse.g. backuprelatedtoa
protecteddatabasea copytotheRA will becreated
•After copyingprocesstheprotecteddatabasewill bedelete
thebackupAutomaticallyfrompollingdirectory
Source: Oracle

22. ZDLRA -in Action2221.06.2017
Installation and Configuration
from bottom up

23. Installation Steps
ZDLRA -in Action2321.06.2017
Create the ZDLRA configuration using
the latest OEDA
Start the Re -Imaging and Setup from the first
Computing Node (like an Exadata Setup)
[root@zdldbadm01 linux -x64]# ./install.sh -cf ./WorkDir/zdl-zdl.xml –r 1-16

24. Installation Steps
ZDLRA -in Action2421.06.2017
Recovery Appliance specific Installation Steps
[root@zdldbadm01 install]# ./ra_install.pl --help
ra_install.pl -Recovery Appliance Installer
You must be logged in as root to run this command.
All steps should be run successfully for install.
Usage: ./ra_install.pl --help | --step=STEP_NUMBER {--install|--uninstall} [--
stdout]
Options:
--help: displays this help message
--step=number: Which step to run
--stdout: Print all messages to stdoutrather then the log file
--install: Installs the step [Default]
--uninstall: Uninstalls the step
Step Numbers:
Step 1 -Validation and Configuration Prep
Step 2 -OS Setup
Step 3 -Oracle User Setup
Step 4 -DBFS Setup
Step 5 -Tape Backup configuration
Step 6 -ZDLRA DB Backup Setup
Step 7 -Enable ZDLRA Services

25. Configuration Steps
ZDLRA -in Action2521.06.2017
Deployment of the Agents on the compute Nodes
Recovery Appliance Discovery
Installation of the Backup Module on any Clients
[oracle@odax30 zdlra]$ java -jar ra_install.jar -dbUser ra_orcl02 -dbPass
manager -host zdlingest-scan -port 1521 -serviceName zdlra -walletDir
/u01/app/oracle/admin/orcl02/xdb_wallet -libDir $ORACLE_HOME/lib
Recovery Appliance Install Tool, build 2015 -11-03
Recovery Appliance credentials are valid.
Recovery Appliance wallet created in directory
/u01/app/oracle/admin/orcl02/xdb_wallet.
Recovery Appliance initialization file
/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/raorcl02.ora created.
Downloading Recovery Appliance Software Library from file ra_linux64.zip.
Downloaded 27189305 bytes in 5 seconds. Transfer rate was 5437861 bytes/second.
Download complete.
[oracle@odax30 zdlra]$

26. ZDLRA -in Action2621.06.2017
Have a look inside
(just particularities)

27. On the computing Nodes
ZDLRA -in Action2721.06.2017
Metadata Database
–RAC Database (also usedforRecoveryCatalog(VPC))
–Non Container Database
–DBFS Mount-Points for Backupand Replicationpurpose
–DBFS added as Cluster Resources
–HTTP Servlet inside the database will be started for communication between the
clientsandtheZDLRA (dbms_ra.startup_recovery_appliance)
oracle@zdldbadm01:~/ [+ASM1] df -h | grep dbfs
[email protected]:/
957M 120K 956M 1% /dbfs_repdbfs
[email protected]:/ 300G 23G 278G 8% /dbfs_obdbfs
SQL> exec dbms_ra.startup_recovery_appliance ;
PL/SQL procedure successfully completed.

28. On the computing Nodes
ZDLRA -in Action2821.06.2017
–ThreenewFS forinternallypurposesareprovided
[oracle@zdldbadm01 ~]$ df-h
Filesystem Size UsedAvailUse% Mountedon
/dev/mapper/VGExaDb-LVDbSys1
30G 15G 14G 54% /
tmpfs 253G 53M 253G 1% / dev/shm
/dev/sda1 504M 72M 407M 15% / boot
/dev/mapper/VGExaDb-LVDbOra1
99G 59G 36G 63% /u01
/dev/mapper/VGExaDb-LVRADump
296G 191M 281G 1% / radump Dump destinationforinternal Stuff
/dev/mapper/VGExaDb-LVRABackup
99G 351M 94G 1% / rabackup
/dev/mapper/VGExaDb-LVOBIndex
296G 191M 281G 1% / obindex
[email protected]:/
957M 120K 956M 1% / dbfs_repdbfs
[email protected]:/ 300G 4.6M 300G 1% / dbfs_obdbfs

29. On the computing Nodes
ZDLRA -in Action2921.06.2017
Backup of Metadata Database
–Done using Export of RASYS Schema every 2 Hours
–Backup Location on DBFS FS: /dbfs_obdbfs/OSB/ra_export
–Scheduling via "anacron"
[root@zdldbadm01 ~]# cat /etc/anacrontab
SHELL=/bin/sh
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
# the maximal random delay added to the base delay of the jobs
#RANDOM_DELAY=45
# the jobs will be started during the following hours only
START_HOURS_RANGE=3-22
#period in days delay in minutes job -identifier command
1 65 cron.daily nice run -parts /etc/cron.daily
7 70 cron.weekly nice run -parts /etc/cron.weekly
3075 cron.monthly nice run -parts /etc/cron.monthly
[root@zdldbadm01 cron.hourly]# ls -l /etc/cron.hourly/
total 4
-rwx------1 root root 409 Nov 10 2015 0anacron
lrwxrwxrwx 1 root root 46 Aug 25 16:20 ra_export.pl -> /opt/oracle.RecoveryAppliance/bin/ra_export.pl

30. On the computing Nodes
ZDLRA -in Action3021.06.2017
ASM Configuration
–Two Diskgroups DELTA(for Backups), CATALOG(Metadatas)
–New special sub-Directory CONTAINER for storing Container Files which
containsDelta Pools and Delta Stores
–Each Container File as a size of 2 TB
ASMCMD [+delta/zdlra] > ls -l
Type Redund Striped Time Sys Name
Y ARCHIVELOG/
Y CONTAINER/
Y DATAFILE/
Y TEMPFILE/
ASMCMD [+delta/zdlra/CONTAINER] > ls -s
Block_Size Blocks Bytes Space Name
512 4294959104 2199019061248 4398059094016 con.365.920823681
512 4294959104 2199019061248 4398059094016 con.366.920823687
512 4294959104 2199019061248 4398059094016 con.367.920823699
...

31. On the cell Nodes
ZDLRA -in Action3121.06.2017
Fortunatelly nothing special ☺
Same appearance as in Exadata Storage Cell
During the Installation the "Write Back" Option will beenabledautomaticallyforthe
Flashcache
Little difference on the Grid Disks compared with the Exadata, only 10 Grid Disks
instead of 12 for the CATALOG ASM Disk Group

32. ZDLRA -in Action3221.06.2017
From protected Databases
to backups

33. Protected Databases
ZDLRA -in Action3321.06.2017
Once the Environment meets all the requirements we can add the databases to the
ZDLRA
The requirement are:
•Network connectivity
•Backup Module is installed for every Oracle Home
•Definition of Protection Policies are created (Retention Time)
Block Change Tracking not mandatory, but recommended !!!
Two Methods are possible:
•Enterprise Manager
•Manually DBMS_RA PL/SQL Package

34. Prerequisite for Adding Protected Database
(EM and manually)
ZDLRA -in Action3421.06.2017
Create an VPD User on the Metadata Database
Grant the Create Session privilege
SQL> create user ra_orcl03 identified by < pwd>;
SQL> grant create session to ra_orcl03;

35. Adding Protected Database with EM
ZDLRA -in Action3521.06.2017
Add Protected Database on Recovery Appliance Page
–Choose the Protection Policy

36. Adding Protected Database with EM
ZDLRA -in Action3621.06.2017
Configuring Backup Settings
–Register database
–Add RMAN configuration (configure...)
–Enabling Redo Transport
(add parameter to spfile and restart DB)

37. Scheduling Protected Database with EM
ZDLRA -in Action3721.06.2017
Protected Database is ready for backing up
–We need a Schedule

38. Scheduling Protected Database with EM
ZDLRA -in Action3821.06.2017
Configure the repeating interval for
the Incremental-Forever Backups
Configure the Archive Log Backups and
deletion rule

39. Scheduling Protected Database with EM
ZDLRA -in Action3921.06.2017
Also useful as Script Generator here the Script is not modifiable !!!

40. Scheduling Protected Database with EM
ZDLRA -in Action4021.06.2017
Output of an Backup Schedule on EM13c

41. Adding Protected Database manually
ZDLRA -in Action4121.06.2017
Add Database for the protected database
Grant access to Virtual Private Catalog
Configure the RMAN Channel for ZDLRA
begin
dbms_ra.add_db (
db_unique_name => 'orcl03',
protection_policy_name => 'bronze',
reserved_space => '250G');
end;
begin
dbms_ra.grant_db_access (
db_unique_name => 'orcl03',
username => 'ra_orcl03');
end;
CONFIGURE CHANNEL DEVICE TYPE 'SBT_TAPE' FORMAT '%d_%U' PARMS
"SBT_LIBRARY=/u01/app/oracle/product/12.1.0.2/dbhome_1/lib/libra.so ,
ENV=(RA_WALLET='location=file:/u01/app/oracle/product/12.1.0.2/dbhome_1/dbs/ra_wallet
credential_alias=zdlingest -scan:1521/zdlra:dedicated' )";

42. Adding Protected Database manually
ZDLRA -in Action4221.06.2017
Enable Real-Time RedoTransport
Restart theDatabase
ALTER SYSTEM SET REDO_TRANSPORT_USER=ra_orcl03 SCOPE=BOTH;
[oracle@odax30 ~]$ srvctl stop database -db orcl03
[oracle@odax30 ~]$ srvctl start database -db orcl03

43. Execute Backup manually
ZDLRA -in Action4321.06.2017
Backups workslike in traditional way
Only "forever" incremental level 1 backups should be schedule
Level 0 Backup are of course always possible
It worksalso withold fashion syntax soft link from libra.so to libobk.so is
needed !!!
Scheduling is also free selectable, EM is recommended !
[oracle@odax30 ~]$ rmantarget / catalog ra_orcl02/manager@zdlingest -scan:1521/zdlra
...
connected to target database: ORCL02 (DBID=3592015831)
connected to recovery catalog database
RMAN> backup incremental level 1 database;
run {
allocate channel c1 type sbt_tape;
backup incremental level 1 databaseplus archivelogdeleteinput;
}
...
ORA-27211: Failed to load Media Management Library

44. ZDLRA -in Action4421.06.2017
CopytoTape

45. PurposeofCopytoTape
ZDLRA -in Action4521.06.2017
Tape Infrastructure providesa secondorthirdcopyofyourbackups
Tape Infrastructure couldbelocatedon different Data Center DR capability!
Tape backupsare"cheaper" forlong-term Storage
High efficiencyisgivenin combinationwithZDLRA
Oracle Secure Backup just pre-installedon ZDLRA

46. Setting upCopytoTape
ZDLRA -in Action4621.06.2017
Configuring Media Management Library
•Library Name
•NumberofDrives
•NumberofRestore Drives
•Media Manager Location (libobk.so)

47. Setting upCopytoTape Template
ZDLRA -in Action4721.06.2017
Template helpstodefinespecificattributes
•Backup types
•Database orProtectionPolicies
•RecoveryWindows will beinherited
•Numberofcopies
•RuntimeWindow
•Schedule

48. ExecutingCopytoTape
ZDLRA -in Action4821.06.2017
With theschedulingwill beiniatiatethecopytotapeprocess
backupsetofdefineddatabaseorprotectionpolicywill becopiedtotape
Long Term Backup shouldbedonewithcopy_backupprocedure
Restores ofbackupsetfromtapewill beretrievedtransparently!!!

49. ZDLRA -in Action4921.06.2017
Recovery Capabilities

50. General statement about Recoveries of protected
Databases
ZDLRA -in Action5021.06.2017
Recoveries of protected databases can be done with EM or manually
With EM several Recovery -Scenarios are possible
All Recovery scenarios with EM are full automated
(e.g. Creation of auxiliary Databases, etc.)
EM generates RMAN Scripts for each Scenario
with the possibility of adaption
Possibility of selection between full and point -in-time
recoveries
Duplicate Database (for standby) need some preparation
(e.g. FS-Structure(admintree))

51. Protected Database Recovery with EM
ZDLRA -in Action5121.06.2017
From database Page under Availability Backup & Recovery Perform Recovery

52. Protected Database Recovery with EM
ZDLRA -in Action5221.06.2017
Choose the needed Recovery Scenario
... You can choose an other restore
location if needed...

53. Protected Database Recovery with EM
ZDLRA -in Action5321.06.2017
A schedule will be created
... And you can adapt the script if needed and submit the job...

54. Protected Database Recovery with EM
ZDLRA -in Action5421.06.2017
The Job can be monitored by clicking the "View Job" button...

55. Protected Database Recovery manually
ZDLRA -in Action5521.06.2017
Restore can be done also manually
–of course db must be mounted before...
–RMAN Client should be configured otherwise parameter are needed (e.g. ENV=...)
Or a point-in-time Recovery
run {
restoredatabase;
recoverdatabase;
alter database open;
}
run {
set until time '08.09.2016 08:45:00';
restore database;
recover database;
alter database open resetlogs;
}

56. Real Time RedoTransport –whathappensreally?
ZDLRA -in Action5621.06.2017
We testedwhathappensreallywhentheprotecteddatabasecrash…
▪Wedida backupofa protecteddatabasewithenabledreal time redotransport
▪thenweshutdownthedatabaseinconsistently(abort)… beforewecheckedtheactualSCN
▪theZDLRA figureout thecrash oftheprotecteddatabaseandcatalogtheredostream fromthe
stagingareaasarchivelogwiththelatestSCN he know… thatwill belatestconsistentSCN for
restore andrecoverthedatabase
RMAN> backupincrementallevel1 databaseplus archivelogdeleteinput;
SQL> select current_scnfrom v$database;
CURRENT_SCN
-----------
28933241
SQL> shutdown abort
RMAN>list backup of archivelogall;
.
.
1 26 28933197 18-APR-17 28933202 18-APR-17
1 27 28933202 18-APR-17 28933232 18-APR-17
1 28 28933232 18-APR-17 28933246 18-APR-17

57. ZDLRA -in Action5721.06.2017
Recovery Appliance Views and
Utilities

58. Some RA Views
ZDLRA -in Action5821.06.2017
It is also possible to read the Recovery Appliance Information over Views from Recover
Appliace Metadata Database
ViewName Description
RA_DATABASE Informationabout Protected Databases
RA_DB_ACCESS Describes User Accounts that have access to which protected database
RA_PROTECTION_POLICY ProtectionPolicies defined on the Recovery Appliance
RA_DATABASE_STORAGE_USAGE Storageusage for each protected database
RA_RESTORE_RANGE DescribeRestore Range for each protected database
RA_INCIDENT_LOG Describe Recovery Appliance Incidents
RA_REPLICATION_SERVER ReplicationServer Information (ifused)

59. rastat.pl Utility
ZDLRA -in Action5921.06.2017
rastat Utility help to evaluate the performance of Recovery Appliance
–NETBACKUP/NETRESTORE
•Measure the network performance
–ASMREAD/ASMWRITE
•Measure the ASM Disk I/O Performance
–CONTAINERREAD/CONTAINERWRITE/CONTAINERALLOC
•Measurethe Container Disk I/O Performance
[oracle@zdldbadm01 ~]$ perl /opt/oracle.RecoveryAppliance/client/rastat.pl --test=CONTAINERWRITE --
filesize=2048M --rasys=rasys/manager@zdlingest-scan:1521/zdlra--diskgroup=/:DELTA
RECOVERY APPLIANCE WRITE IO TEST TO CONTAINER FILES
Disk Group: /:DELTA
2048 MB, .75s writeIO time, .51s CPU time, 2724.80MB/s, 68.51% CPU usage
PL/SQL proceduresuccessfullycompleted.

60. dbms_ra Package
ZDLRA -in Action6021.06.2017
dbms_ra provides administration function from inside the RA Database
Ca. 50 Procedure for different types of administration
–Start/Stop of Recovery Appliance
–Add/Delete Protected Databases
–Grants Access to specific User to enable to backup and restore
–Add/Update Protection Policies
–Manage Tape Configuration (if available)
–Add Repliaction Server (if available)
But, the utilization of Enterprise Manager is recommended !!!

61. ZDLRA -in Action6121.06.2017
Conclusion

62. Conclusion
ZDLRA -in Action6221.06.2017
ZDLRA worked in our Tests as
expected
Very good implementation of well
known Backup and Recovery
Technology on EngineeredSystem
RPO is (near) zero with Real Time
Redo Transport
Even RTO ist much better then
existing systems
Very simple Management with EM
Riskreduced, costreduced,
qualitiyimproved
ZDLRA will find it’s
customer !

63. Questions and Answers...
Daniele Massimi –Principal Consultant
Tel. [phone]
[email protected]
21.06.2017ZDLRA -in Action63