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

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