Ok, did you copy the new objects over from the other server... the ones that we modified?
OK let's try this... replace the input params for the AGInfo SP with these. I think when we were tshooting the other day we didn't enable all the defaults back.
(
@DBName NVARCHAR(400),
@DBIsInAG BIT = 0 OUTPUT,
@IsPrimaryReplica BIT = 1 OUTPUT,
@IsPreferredBackup BIT = 1 OUTPUT,
@AGRole VARCHAR(10) = NULL OUTPUT,
@AGName NVARCHAR(100) = NULL OUTPUT,
@PrimaryNode VARCHAR(200) = NULL OUTPUT,
@AG2ndaryReadMode varchar(10) = 'All' OUTPUT
)
That worked for both issues in Test. The errors are no longer occurring there. I will deploy to Acceptance and beyond where we do have Availability Groups.
Thanks!
Hi Sean,
We're still having a little ripple effect. The backups on the existing SQL Servers are still working well. After the last fix, I put all of the install files, including the latest fixes, together.
We just built a new server with an Availability Group. The Minion Backup installed cleanly. The system data bases are backing up normally. But when I created a new data base and put it in the Availability Group, the backups returned this error:
FATAL ERROR: @BackupCmd is empty. Common causes are misconfigured BackupSettings and BackupTuningThresholds tables.
This message came up whether I used BackupMaster or Backup DB, and happens whether the backup is full, differential, or transaction log.
A native SQL Server Backup Database command worked without error.
I then created another data base but did not put it in an Availability Group. Backups for those worked normally.
I checked the configurations, and they look correct (it's the same whether or not the DB is in an AG). I also scripted out the stored procedures that were changed from the new SQL Server and from an existing, working SQL Server and did a compare between the two, and they matched.
My suspicion is that it's something about a call or parameter default to one of the stored procedures, or that something was missed packaging up the changed procedures / functions.
Do you have any suggestions as what to look at?
Thanks!
Sean,
I ran a SQL Compare between the SQL Server we originally worked on for the Arithmetic Overflow and subsequent AG errors, and the SQL Server currently having the problem with Minion backup. (The original is not an AG and has Minion Backup in its own DB; the problem server is an AG and has Minion Backup in master, but those shouldn't matter for the code base. They should both be version 1.5)
The SQL Compare showed only one stored procedure as different: Minion.DBMaintDBSizeGet.
On the problem server, I renamed then SP and then copied the SP from the original server to it. It now showed all Minion objects being equal between the two servers.
However, when backup job ran at its next interval, it threw the same error.
(The other SQL Servers are version 1.4 with just the changed procedures and functions applied, so show many differences in the SQL Compare).
What do you suggest for the next step?
Richard Seltzer
I have Minion Backup 1.4 installed on many of my SQL Servers, and on several (including Production), I am getting fatal arithmetic overflow errors when it tries to do a full or a differential backup. Transaction log backups continue to run successfully.
The Status column of the BackupLogDetails menu says "FATAL ERROR: Arithmetic overflow occurred."
Other backups on the Production server are running successfully.
There is no error message in the SQL Server Error Log around that time, so I believe this is a Minion Backup issue. I don't see any other information abut the error in the Minion logs.
Please advise as soon as possible