February 24, 2020 at 5:59 pm
I'm working on getting these scripts set up to run my backups on some new servers (OS: Win Serv 2016, SQL Server 2014) and on at least one noticed something odd.
A database was backed up twice within a couple minutes of each other. This happened at about 1am and 1:05am, so it wasn't someone manually firing off a backup of the DB. I do have the scripts configured for, and the Agent jobs set up, to backup databases in parallel (2 jobs.) The parameters on both Agent jobs are set exactly the same, the schedules are the same, etc.
This is the first time the job has run, so I'm going to keep an eye on it and see if it happens again the next full backup (Differentials from this AM did not do this,) I'm just curious if anyone else has seen similar behavior.
February 25, 2020 at 6:10 pm
Thanks for posting your issue and hopefully someone will answer soon.
This is an automated bump to increase visibility of your question.
February 26, 2020 at 8:49 am
You have the @DatabasesInParallel param set to Y correct? You also have the queue tables etc and got Ola's latest code base?
As a side note why are new servers being deployed with SQL2014, its out of mainstream support, surely you would want to be putting in at least 2016, if not 17 or 19?
Do you have extended support rights or are you running this at risk that Microsoft will not help you if there's an issue with it?
February 26, 2020 at 2:24 pm
You have the @DatabasesInParallel param set to Y correct? You also have the queue tables etc and got Ola's latest code base?
As a side note why are new servers being deployed with SQL2014, its out of mainstream support, surely you would want to be putting in at least 2016, if not 17 or 19?
Do you have extended support rights or are you running this at risk that Microsoft will not help you if there's an issue with it?
Yes, I do have the @DatabasesInParallel param set to Y, fairly sure I've got the most recent version of the scripts (I downloaded the script only a few weeks ago and all the servers were loaded from the same script.) Discovered when I tried to do a test run of the backup about the queue table, so grabbed the scripts to create those.
We're actually on the current Service Pack for SQL 2014, we're migrating to a cloud provider and chose to stay on the same version of SQL as we're on in-house to minimize the changes happening at once. After we get "cloudified" and things settle down, my next big project will be migrating everything to SQL2019.
February 26, 2020 at 3:01 pm
The only thing then is going to be the 5 minute wait, if your doing parallel backups then the jobs should really start at the same time.
Guessing the database in question is small enough that its backed up quick enough within the 5 minutes so that the next run comes in and says "ah it needs to be done".
I tested it on a copy of AdventureWorksDW and a tiny DB, doing them on 2 spids straight away it does them separately. Leaving it 30 seconds it backups adventure works again as its moved onto the other DB on the other thread.
February 26, 2020 at 8:16 pm
Guessing the database in question is small enough that its backed up quick enough within the 5 minutes so that the next run comes in and says "ah it needs to be done".
Hmm, which would be interesting, because the database in question has a Filestream component of ~110GB so I wouldn't think it would've finished that quick. I'll have to take a look at it tomorrow when I'm back on the clock.
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply