I have Oracle backups running which are scheduled through RMAN which occasionally fail with the following error code:
“Error Code: [82:177] Description: Timeout while waiting for a reply from DeDuplication Database engine for Store Id [X]”
Steps that I have taken to troubleshoot the issue:
- Dedupe engine is active and running
- Created a one way persistent tunnel from the client to the commserve and Media agentsas suggested by another thread pertaining to the same issue “ERROR CODE [82:172]: Could not connect to the DeDuplication Database process for Store Id [xx]. Source: xxxx, Process: backint_oracle | Community (commvault.com)”
Our Q&I times across the board for our media agents are quite high. For this particular engine the times are 6,416 microseconds (307%). I believe the ddb is not running on SSD, but regular disk. Is it possible that this could be causing the above error? If not I’m not sure what else could be the reason for this.
I doubt it but this merits a ticket.
@Rehan Bari ,
Raising a ticket for this would help you to get it fixed, or at least to have the troubleshootings steps applied to your environment done properly.
Otherwise, yes, this could be a reason. Depending on how often it occurs, and mupltiple other items, this could also be because you’ve got a DDB backup running at the same time of the Oracle backup, for example.
And to check, Q.I time you mention is 6416ms, or 6ms416 ? 6ms is not that big, while 6416 is 6 seconds is huge..
Or you may have multiple DDBs on the same disk
Or you may have non dedicated disk for the one hosting this DDB (like shared with other data already in use at the moment of the backup).
Or you may need to seal /compact DDB as it could be too old/fragmented.
Or check the properties of the subclient / Storage Device / Deduplication tab, to see where the signature is generated : client of media agent side.
This is just part of troubleshooting questions, as you can see, so yes, it could be better you call the Support for such. 😉
In my case, this was caused by teh network drop everytime. So I tacked this with one way firewall.