Backup and Recovery - Expert Consolidation in Oracle Database 12c - page 388

COUNT(1)
----------
73754
73753
73753
0
0
USER1@PDB1> select count(1) from t_1;
select count(1) from t_1
*
ERROR at line 1:
ORA-00942: table or view does not exist
After the import you can decide how you want to merge the contents of the restored tables with the live tables.
Taking RMAN backups
You read in the introduction that taking of backups is an essential part of the daily routine. It is equally important that
the backup return code is reported back so that failed backups can be triggered manually if required and possible
during the day. The backup frequency and the contents need to be defined by the owners of the database hosting
service and presented to its users as a choice. There should not be too much choice so as not to confuse the users,
and each option should be explained in simple terms understandable to the non-technical audience. The managers
requesting a Pluggable Database most likely do not have a database background, nor do they need to have one. So
instead of using cryptic-sounding technology terms such as “weekly level 0 backup on weekend, then differential
incremental backups every evening” you could say “a full backup is taken on the weekend with additional backups
during the week, capturing each day's changes individually” or similar. It is important for the person raising the
request to understand the implications of different backup techniques. If you decide to offer a logical backup of
the PDB as an option, it must be made clear that there will not be a point in time recovery, and a completely empty
PDB has to be created first. The last thing the managers of the hosting service need are outages caused by improper
documentation of the backup techniques! Transparency and openness will greatly help the service to
gain acceptance.
Considerations for the Recovery Catalog
Backup information can either be stored in the database's control file or alternatively in a so-called catalog database.
Although the use of a recovery catalog is not mandatory there are good reasons for using one. First of all, should you
lose all controlfiles of a database due to a catastrophic failure there is a probability that you have lost the backup
information with them. Recovery of the database is still perfectly possible but involves extra steps.
A Recovery Catalog is a schema in an Oracle database, which is initialized with data structures required
for RMAN to store information related to backups. To create the catalog you first need to create a new user in
a database, and then connect to it from within the RMAN executable to create the schema. It makes sense to
dedicate a tablespace to the RMAN catalog in the database. The catalog database should be considered part of
the infrastructure and not part of an operational database for obvious reasons. Depending on your organization's
structure you could have a catalog database per region or multiple databases per region and/or tier. Whichever
way you decide, your catalog schema has to be in a dedicated database. Please do not forget to back your catalog
database up at regular intervals!