Start a new topic

Fatal Arithmetic Overflow Error for Minion Backups on Production and Other SQL Servers

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



Hey Richard,

I'll be glad to work with you on that.  I think I've seen it before.  Would you be interested in trying a pre-release of 1.5?

Hi Sean,


How stable is 1.5, since this is happening in Production as well as Test (and I’m not sure where else, as I haven’t yet implemented the MB alerts mentioned in the manual)?

 

I am willing to try 1.5 in Test first, but whatever we do, we have to get the fix to production very soon.


Thanks!


The build itself is quite stable, I just haven't had a chance to fully test the installer.  Let me take a few mins to run the installer on a test box and run a couple backups to make sure all the objects are there and then I'll post it here for you.

I just installed and tested this and I was able to run all 3 backup types. 


zip
I will test later this afternoon and let you know the results. Thank you.

Got the zip file.  I assume I install it the regular way (same as when first installed, with PowerShell script) and it will keep the existing configurations in the tables?

Yep, just put it in the install folder and run the installer.  It should handle any upgrades needed, and it doesn't touch your data.

Hi Sean,

 

I installed, ran Minion.Help to make sure it was 1.5, then ran full backups manually:

 

exec Minion.BackupMaster @DBType = 'System', @BackupType = 'Full', @Include = 'All'

exec Minion.BackupMaster @DBType = 'User' , @BackupType = 'Full', @Include = 'All'

 

 

They all got the same result (I replaced our server name with asterisks):

 

FATAL ERROR: Msg 2812, Level 16, State 62, Server ********, Procedure Minion.BackupDB, Line 899 Could not find stored procedure 'Minion.MMAGInfo'. Msg 2812, Level 16, State 62, Server ********, Procedure Minion.BackupStmtGet, Line 1202 Could not find stored procedure 'Minion.MMAGInfo'.

Oh well that's only cause I forgot to include the shared folder.  Just rename your old one.


zip
(57 KB)

I put the new Shared folder in and reinstalled.  No more missing SP, but back to the Arithmetic Overflow and also, for system DBs, a folder creation error (which was happening in 1.4 as well), even though the system DBs are using the same path definition in BackupSettingsPath,


I took the entry in BackupSettingspath and pasted them into File Explorer and it had no problem opening the share.


This is in Test.  In Production, with 1.4, we are not getting the folder error, only the Arithmetic overflow error, and there only on one data base for full and differentials.  The full and differentials work on the other data bases, and the log backups work on all of the data bases.


Here are one each of the errors from the Test server:


FATAL ERROR: Arithmetic overflow occurred. 


FATAL ERROR: We were not able to create the folder in the path specified. Make sure your settings in the Minion.BackupSettingsPath table are correct and that you have permission to create folders on this drive. ACTUAL ERROR FOLLOWS: Error: MD : The path is not of a legal form.   


1.  AO error - I just remembered this may be an issue with the DBSize SP.  Run the code below and let me now what happens.


2.  Path error - Run BackupDB with @StmtOnly = 1 and make sure that the path being printed is what you want.  The error says that it's not in the right format.  You may be having trouble with the Inline Tokens.


<span class="fr-marker" style="line-height: 0; display: none;" data-type="false" data-id="0"></span><span class="fr-marker" style="line-height: 0; display: none;" data-type="true" data-id="0"></span>declare @OpName varchar(20), 
    @DBSize decimal(18, 2), 
    @Module varchar(20), 
    @DBName varchar(200);
set @Module = 'Backup';
set @DBName = 'MinionDev';
EXEC [Minion].[DBMaintDBSizeGet] @Module = @Module, @OpName = @OpName, @DBName = @DBName, @DBSize = @DBSize OUTPUT;
select @DBSize; 


If that script returns an error then try the attached version.

I may be slower to reply this wknd but I'll still be around.

sql

The script ran and returned a value of 1.00


The Path error looks like something different -- when I ran a manual backup to the fileshare, it errored out saying the account is disabled (even though it could still remote in, access the share explicitly, and is running the SQL Server instance).  I have my Windows support person looking at that and at AD.  But we're not getting any path errors in Production where we are getting an AO error on a large data base.


Now, it seems more (but not all) of the data bases in Test are getting Path errors instead of AO errors, so that may be progress with 1.5.


Let me know what other info you need.

Well, I'd say that if the path being returned is correct, then there's nothing more I can do.  Did you check the path, and is it correct?

Don't worry about the Path issue.  That's separate.


Many of the data bases are still getting Arithmetic Overflow errors.


Is there a way to identify where in the Minion Backup code that is happening?

Login or Signup to post a comment