Archiving should be enabled for your production database; otherwise, you will not be able to do a point-in-time recovery. You can use RMAN out of the box to run commands such as this to back up your entire target database:
$ rman target /
RMAN> backup database;
If you run this command at the CDB level, it will back up your container database and all pluggable databases in the container.
If you want to just back up the CDB, so this:
$ rman target /
RMAN> backup database root;
From the CDB you can also back up just the pluggable databases by listing them:
$ rman target /
RMAN> backup pluggable database mmpdb, salespdb;
You can also back up a database from any of the pluggable databases and just back up the PDB you use as the target.
If you experience a media failure, you can restore all data files, as follows:
RMAN> shutdown immediate; RMAN> startup mount; RMAN> restore database;
After your database is restored, you can fully recover it:
RMAN> recover database; RMAN> alter database open;
You are good to go, right? No, not quite. RMAN’s default attributes are reasonably set for simple backup requirements. The out-of-the-box RMAN settings may be appropriate for small development or test databases.
But, for any type of business-critical database, you need to consider carefully where the backups are stored, how long to store backups on disk or tape, which RMAN features are appropriate for the database, and so on.
The following sections in this chapter walk you through many of the backup and recovery architectural decisions necessary for implementing RMAN in a production environment.
RMAN has a vast and robust variety of options for customizing backups, managing backup files, and performing restores; and, typically, you do not need to implement many of RMAN’s features. However, each time you implement RMAN to back up a production database, you should think through each decision point and decide whether you require an attribute.
Run RMAN Remotely or Locally
If you run RMAN remotely, make sure you are using the same version of RMAN. It needs to be compatible with the Oracle database. If you run RMAN locally, you are using the same version as the database.
Running remotely allows for backups to be run from one central location, even if the backup files are created on the target database server.
Specify the Backup User
As discussed previously, RMAN requires that you use a database user with SYSBACKUP privileges. Whether it is running RMAN from the command line or invoking RMAN in a script, using a backup user is appropriate. For example, here is how to connect to RMAN from the command line:
$ rman target BACKUPUSER/$password
