It was just a matter of time until I started combining my cloud experience with “different” flavours of SQL Server. I haven’t used Linux since my university days (Oracle – errgh) but recently some Friends of mine ( using LAMP stack ) asked me couple of questions about SQL Server Linux.
There are many quality resources regarding SQL Server 2019, from eBooks to videos about the newest features and how one would implement these within your business. I recommend the following book, not because I was co-author, more so of the fact that the other authors have brilliant chapters giving quality high level information (with enough detail) to understand SQL Server 2019.
I mean, who better than Buck Woody to talk about Big Data Clusters???!
Unfortunately, this is not an on-premises SQL Server install because I do not have the right operating system available for SQL Server 2019, which includes the below:
- Windows 2016 +
- Red Hat 7.3-7.6
- SUSE v12 SP2+
- Ubuntu 1.8
So, I am going to use my clicking skills and spin a Machine up in Azure utilizing the market place, so I can get an image of SQL Server installed on the VM already.
Having worked with Azure SQL Database and its many flavours for couple of years now I am confident in building deploying, whether manual or templates. Being in Azure you can take the same mind set to build non-Microsoft database tech such as PostgreSQL, MySQL etc.
Let’s work though one, it’s that easy.
This post is to help you if you are suffering from the following issue:
A VSS writer has rejected an event with error. The writer experienced a non-transient error. If the backup process is retried, the error is likely to reoccur. Changes that the writer made to the writer components while handling the event will not be available to the requester. Check the event log for related events from the application hosting the VSS writer.
Consider the following scenario:
- You have a server that is running any version of Microsoft SQL Server.
- This SQL Server instance hosts databases that have the AUTO-CLOSE option set.
- You run a non-component VSS backup (for example, by using Azure Site Recovery (ASR) Agent) against volumes of this server that is hosting SQL Server database files.
In this situation, you notice that the VSS backup fails and triggers the following entry in the Application log.
Do you enable this setting to allow automatic tuning to care of all your performance needs? Well not ALL your needs, more so:
- CREATE INDEX
- DROP INDEX
- FORCE LAST GOOD PLAN
SQL Server 2019 is ready available for use, but before you download you should review the webinars, white papers and eBook available on the technology (definitely the eBook 😉 ).
You can find the eBook at the following link –
I think many have covered how you should backup your SQL Server database to Azure storage (also known as backup to URL) but what about restoring? Lets assume you have setup backups and they are working, this is what I usually do.
Would you like to troubleshoot a deadlock in Azure SQL Database? To do this you probably will be after the deadlock graph. So does this mean that you need to setup your own extended event session? No, it doesn’t.
In the previous blog post I did a quick overview building a SQL VM (imaged) in Azure. It is now time to clarify some backup techniques because it can get confusing.
At a high level there are 3 techniques.
- Automated backup.
- Azure backup for SQL VM (that’s what MS call it).
- Manual backup, for example backup to URL.
I prefer not setting up manual backups to storage accounts, I have done it, I just find it painful to setup/support/fix. So my choice would be automated backup vs “Azure backup” for SQL VM. What’s the difference?