Skip to main content


 

 

How can we help you?

 

 
Druva Documentation

New authentication changes for Oracle DTC with new agent version

Heads up!

We've transitioned to a new documentation portal to serve you better. Access the latest content by clicking here.

 

Problem description

  • Prior to version 6.1.2, Druva agent used to perform validation, discovery, backup and restore using sysdba role by default.
  • Due to usage of such a command, in case of OS/Oracle authentication, even if the user is not available or credentials are incorrect, then also validation would succeed (because oracle itself fallbacks to sysdba if service name is not mentioned).
  • Due to the above scenario, it might happen that on current production, configured databases could be working even with the following:
    • invalid credentials
    • credentials without sysbackup/sysdba permission.
  • In order to not have any impact on existing backupsets, we have kept the agent backward compatible. Agent will decide based on the available metadata for existing backupsets if it needs to fallback to sysdba role by default or not.
  • Because of the above change following user may face below scenarios and will have to perform steps given in the solution section

Scenario 1:

  1. OS/Custom user was not created in 6.1.x.x version
  2. Druva agent is upgraded to 6.1.2.x,
  3. Authentication is updated with the new user.
  4. Backup is performed after changing the authentication
  5. User trying to restore from RP created by version 6.1.x.x and the user used in step 2 is not present in DB after restore

Impact

As, the user is not present in restore RP and authentication is assigned with the new user, the backups would start failing with authentication error.

Resolution

Create the user on DB after restore

Scenario 2:

Unable to assign authentication with the custom user on restored DB

  1. Custom users are created on the source DB
  2. User performs DB cloning(Automated restore to alternate server)
    1. User tables from DB are cloned and entries are seen in the users table on the target server.
  3. But we are unable to authenticate DB using the cloned custom users on Druva cloud

Impact

Authentication would fail on the restored DB Druva

Resolution

  1. Copy the password file from the source server to the target server
  2. The default path of password file for a database is present at location $ORACLE_HOME/dbs/orapw<sid>
  3. User needs to copy this file from source server to target server