It is not uncommon to find a wide range of situations among our customers in terms of virtual machine performance with SQL Server. In many cases, we find situations where performance levels are far from ideal but, in general terms, virtual machines themselves are not to blame. What usually happens is that when we move SQL Server to a virtual machine, we become constrained by a maximum or limited amount of resources (CPU/ memory/ IO) that is significantly different to that of the physical machine. (more…)
Gradually, as storage gets faster and local SSD storage becomes more popular, etc. disk access times are significantly decreasing. In these regards, perhaps the best example are the SSDs Optane systems, notable for their much lower read/ write latencies than with traditional SSD’s, in addition to being directly connected through the PCIe bus: (more…)
In the last few years, we are increasingly finding more hybrid environments where some SQL Servers are being migrated to the Cloud. In these cases, other applications, services, ERPs or even SQL Server instances continue to be based OnPremise in the initial data center. This means that in the event of any connections between both environments, these will be restricted by bandwidth and higher latencies, as opposed to other connections that do not go across both environments.
One of the issues that many of our customers face when attempting to migrate OnPremise instances to the Cloud is the lack of a simple “shared storage”. Although there are some alternatives supported by third-party software or SDS solutions that allow us to configure a Failover Cluster instance in Azure, these are highly complex, therefore adding significant further costs to the solution’s TCO.
I’m sure that the most “senior” readers will remember the possibilities available in old SQL Server versions to do backups using named pipes. And by older versions, I mean “really old”, since this functionality was marked as obsolete in SQL Server 7 and, although it remained in SQL 2000, it was completely removed from SQL Server 2005 and later versions.
In an on-premises environment when we propose solutions to geographical disasters, the most common option is log shipping. The use of asynchronous database mirroring or availability groups with asynchronous replicas is also common but includes an additional risk that is not usually contemplated. We refer to the “speed” with which the changes are transferred, as quickly as the network and the target system allow us. This means that when the disaster has a human origin, an important error when we become aware of it, we will have this error replicated and applied. Obviously, a better solution would be to combine both options, which are not exclusive, with which we would cover more disaster scenarios increasing the cost of the solution. (more…)
Lately, we are noticing a trend whereby traditional SANs are increasingly losing ground. This can be due to various reasons, such as forced migrations to the cloud, limited budget environments or even customers who are getting annoyed with their storage providers’ draconian terms and conditions. A common example is to find very costly maintenance agreements, higher-than-market disk size upgrade costs, as well as difficulties to expand/ improve hardware without having to completely replace it. There is also a strong trend to continue going virtual and trading servers like they were commodities. All the above is therefore contributing to an increase in this trend towards SDS, while the VSANs continue to attract new supporters.
Over time, our databases get bigger and bigger. One possible solution to reduce this problem is the use of backup compression. Mind you – wouldn’t it be better to start by reducing the volume of information to back up? In databases, most of the information to be backed up is in these three types of object: