Skip to main content

How can we help you?

Druva Documentation

Troubleshoot Oracle scenarios

Phoenix Editions: File:/tick.png Business File:/cross.png Enterprise File:/tick.png Elite

 

Failure of database discovery 

The discovery of databases hosted on the Oracle servers that are registered with Druva Phoenix may fail due to the following reasons:

  • PhoenixOracle service is not running.
  • The Oracle database instance is offline.
  • The database name is not available in the DBA registry (/etc/oratab).
  • Database authentication is not defined.
  • Databases on the Oracle server host are disabled for automatic discovery.

Failure of RMAN backup 

RMAN backup jobs might fail due to the following reasons:

  • If the user-specified does not have the SYSDBA privileges to perform RMAN backups.
  • The database is not in the ARCHIVELOG mode. The Perform an offline backup if database is in NOARCHIVELOG mode check box in the RMAN Settings section of the backup policy is not set.
  • PhoenixOracle service is not running.
  • Offline RMAN backup might fail with the following error: 
    TNS:listener does not currently know of service requested in connect descriptor
    If the database is in the NOARCHIVELOG mode, ensure that you do not use the Oracle listener to connect to the database. When the database is in the NOARCHIVELOG mode, the database is shut down and brought to the mount state. When the database is shut down, the TNS is turned offline and therefore TNS does not work in the NOARCHIVELOG mode.

Snapshot restore failure

Restore databases from snapshots might fail due to the following reasons:

  • Insufficient space on the Oracle server host on which the snapshot restore is requested.
  • RMAN does not have enough permissions to read downloaded backup data.
  • An invalid path is specified in the Restore Location box on the Restore Target page.
  • While restoring data to an alternate Oracle server, the hostname is incorrectly specified.

Scenarios when the Oracle incremental backups get converted to full backups

Overview

When an incremental backup is triggered, the Phoenix agent requests information about databases that are updated. Druva Phoenix backs up the changed data and creates a snapshot in your storage. During the incremental backup, the changed blocks (delta) from the data files are backed up, but the log files are skipped. 

This section lists multiple scenarios due to which the incremental backups get converted to full backups.

Scenarios

Druva Phoenix converts incremental backups to full backups, if: 

  • The incarnation of the database, which is being backed up changes.
  • The archived log sequences are missing after the last backup.
  • Data corruption occurs during the last backup of a database.
  • An incremental backup of a database for which a full backup is not complete is attempted. 
  • A new database file is added to or deleted from a database since the last backup.
  • A database file is renamed or moved since the last backup.
  • A database was renamed.
  • Inconsistencies between the uploaded database files and their metadata are detected. 
  • The master database was included in the last full backup, and the path or name of the master database files changed since the last full backup.
  • A full backup fails, then the next incremental backup will be converted to a full backup.
  • If a full backup is executed by the Phoenix agent and the second full backup is being executed by a third-party backup tool or an Oracle Server. Then the Phoenix agent can convert the next incremental backup to a full backup. 
  • If a database is encountered as shrunk since the last full/incremental backup, Druva Phoenix converts the subsequent incremental backups to full backups. 
  • If a database is reconfigured, Druva Phoenix converts the next incremental backup to full.
  • Was this article helpful?