If you have come from a windows background you may be curious about the world of SQL Server Linux. Yes, the operating system and the implementation of it differs to the traditional Windows environment but once installed, it’s just good old SQL server and those lovely DBCC commands and backup statements work, all your DMVs are ready for you too.
Being in the cloud does have many benefits, from lower administration to fast scaling but another “side effect” of operating in Azure SQL Database is the cloud first nature of changes. By this I basically mean new features always get pushed to Azure first before the classic on-premises version so some gems come to light.
Quick video showing you how to failover your Azure SQL Database between your primary and secondary location.
Since SQL Server 2016 we could leverage Microsoft Azure to dynamically move “cold” portions of data away from on-premises storage for longer retention time periods. Whilst in theory being a great idea the cost was a blocker for some and with a cumbersome setup process. SQL Server 2019 addresses this by making the costs of storing the data in the cloud more competitive and making the setup more streamlined with the use of the Data Migration Assistant (DMA) tool and SSMS (SQL Server Management Studio).
Note: DMA tool replaces the older Upgrade Advisor tool. To install DMA please see the following link https://docs.microsoft.com/en-us/sql/dma/dma-overview?view=sql-server-ver15.
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:
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:
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:
