Best Practices for Retail Pro Prism Advanced Backup Tool
In case of emergency, you should always keep a recent backup of your database.
With the Retail Pro Advanced Backup tool, you can create backups of the Oracle Prism schema. The Retail Pro Advanced Backup tool utilizes Oracle RMAN which is a powerful, flexible, and reliable backup tool that is widely accepted as "the" backup solution for any Oracle database.
There are numerous advantages to using the Retail Pro Advanced Backup tool over the backup options in the Tech Tool Kit for your backups.
- Online (hot) incremental, or differential backups. Eliminates the need for scheduled down time
- Full or Point in time restoration of the database or data file
- Backup validation at the block level
- Utilizes and provides the full functionality of Oracle RMAN utility
- Native encryption and multiple levels of compression are available
- Little or no impact for backups. The time required to complete a backup is 4 to 5 times faster than the Tech Tool Kit backup and it can be done at any time (even during business hours), usually with no noticeable impact to user access.
- Advanced custom backup solutions
- Automatically update image copy (minimizes backup time and MTTR)
- Manage backup priority
- Backup replication (duplex backups)
- Fast Incremental backup
- Tape backup
Best Practices
First review your backup strategy and/or outline your recovery SLA's. See general best backup practices as outlined in the article, Best Practices for Backup of Retail Pro Prism 3-2-1 Backup System.
Below are some of our recommendations along with examples. Please evaluate whether these align with your backup strategy.
Backup retention policy
Keep multiple copies of your backup. We recommend keeping 2 or more: one onsite and one offsite (local disk, remote cloud, tape, or other storage solution).
Setting up your retention policy in the Retail Pro Advanced Backup Tool can be done in several different ways and is completely dependent on your backup strategy.
Examples:
Operation |
Command |
Ensure that RMAN retains all backups needed to recover the database to any point in time in the last 7 days |
RMAN> CONFIGURE RETENTION POLICY |
Retain three backups of each data file |
RMAN> CONFIGURE RETENTION POLICY |
Delete/purge backups no longer required by the retention policy |
RMAN> DELETE OBSOLETE |
Backup optimization
This option will optimize your backup by eliminating the need to make copies of data files when they already exist on the allocated storage device.
How to enable and disable this option:
Operation |
Command |
Turn on optimization |
RMAN> CONFIGURE BACKUP OPTIMIZATION ON; |
Turn off optimization |
RMAN> CONFIGURE BACKUP OPTIMIZATION OFF; |
Set your default device type
This will set the location where you store the backup set.
You can do this for multiple locations but generally Disk (local disk) is the location of choice for most users.
Operation |
Command |
Configure to save to physical disk |
RMAN> CONFIGURE DEFAULT DEVICE TYPE TO DISK; |
Backup storage
It is helpful to name and define the storage location on the disk for the backup and the control file.
Examples:
Operation |
Command |
Defines where to store backup files and file name and formatting. |
RMAN> CONFIGURE CHANNEL DEVICE TYPE DISK FORMAT 'D:\backups\RP_BACKUP_%d_set%s_piece%p_%T_%U';; |
Defines where to store control file backups and the file name and formatting. |
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO 'D:\backups\oradata\CtrlFile_%F'; |
Backup control file
The control file is critical for the backup and restore process.
It contains all the information about the DB, including details about the backups.
Configure the system to create an automatic backup of the control file.
Example:
Operation |
Command |
Automatically backup control file |
RMAN> CONFIGURE CONTROLFILE AUTOBACKUP ON; |
Archive log deletion policy
We generally recommend that that you keep 2 or more backup copies of your archive logs (prior to purging them) if you have room for this.
Log files can quickly grow and consume disc space, so this may not always be physically possible.
This can and should be defined in your backup strategy.
Example Operation |
Command |
Makes 2 disk copies of each archive log file |
RMAN> CONFIGURE ARCHIVELOG DELETION POLICY |
Enable log in in the event of a system restore
To restore a database from a down state, the system will look to the DB first to verify user access but if it is down, it will look and validate access against the db.sec file.
You must have exported the user security file from Retail Pro and run the console from the directory where that exported security file resides.
Creating a backup
We have found that a full backup can be done in most cases in less than an hour, so we recommend full backups for most users (as frequently as daily).
In rare cases if the backup strategy requires more frequency than daily, then incremental(s) can be take throughout the day. This can be adjusted to align with your backup strategy.
A full backup gives you some advantages when it is necessary to restore a system, since the nearer you are to the full backup, the quicker you can complete the restore process.
Here are two examples of an online full backup from the Retail Pro Advanced Backup Tool.
These examples will purge archive logs automatically based on your defined policy.
The following examples also run a few crosscheck commands which ensure the RMAN repository (location and existence of the backups that RMAN has taken) is current.
Example Operation |
Command |
Take a full backup of the database, archive logs; validates the repository and purges |
RMAN> CROSSCHECK archivelog all; |
Use this option in the event you are short on local disk space (lacking space for 2 or more backups) and need to delete the prior backup before you start the current backup. This will also eliminate accumulating archive files.
|
RMAN> CROSSCHECK archivelog all; |