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.
Ok, so Azure SQL doesn’t really have its own error log based somewhere on a machine within \\MSSQL\Log directory but the closest thing you will get is a system catalog view called sys.event_log which is very useful. It will get you information about all sort of event types such as:
- Successful connections
- Failed connections
- Throttling issues
- Blocked by firewall attempts
- Connection termination
The full message when connecting to your Azure SQL Database is:
Reason: An instance-specific error occurred while establishing a connection to SQL Server. The public data endpoint on this server is not accessible. To connect to this server, use the Private Endpoint from inside your virtual network. (.Net SqlClient Data Provider)
I always wanted a way to schedule commands within Azure SQL Database. Personally, for me, the go to standard is the functionality of SQL Server Agent. Obviously, this is not possible out of the box but I have been using an on-premises SQL Server instance (within a specific vnet that is mapped to the logical Azure SQL server) with a linked server connection setup (with dedicated logins) to Azure SQL Database to run some code at a specific time to scale up (and down) my database dependent on peak hours.
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.
For some reason I have friends / colleagues telling me that when scaling (up and down for this example) that no downtime occurs. Well, not only does Microsoft documentation say differently, I will show it. So let’s test it out. Before the practical test, this is the official stance. “There is a switch over period where connectivity is lost to the database for a short amount of time, which can be mitigated using retry logic”.
Wouldn’t it be nice if we could access one main dashboard / report that pulls in information from many tools such as security centre, SQL advisor and cost management tools? Well you can, thus giving you a focal point to implement best practices, called Azure Advisor. This is not specifically for Azure SQL Database, you can leverage this for most resources within Azure. Later in this blog post you see that I will use it as a focal point for my database infrastructure in Azure.
In the Azure portal under services look for “advisor”
After much reading through the internet looking for Amazon’s equivalent of Microsoft’s Azure functions (Lambda), I found this outstanding link that ” helps you understand how Microsoft Azure services compare to Amazon Web Services (AWS). Whether you are planning a multi-cloud solution with Azure and AWS, or migrating to Azure, you can compare the IT capabilities of Azure and AWS services in all categories”..
This is extremely handy and wanted to share it with you.
This is by no means a complete list but more of a personal list of features I have seen not setup or just missed out when looking at Azure SQL DB. After reading, not only will I hope that you agree but it may provoke you to double check your setups.
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.