Developpez.com
Accueil
In a previous blog post, I wrote about reasons we moved our monitoring of on-prem SQL Server instances on Prometheus and Grafana. But what about Cloud and database services?
In a past, I went to different ways for improving update statistic maintenance in different shops according to their context, requirement and constraints as well as the SQL Server version used at this moment. All are important inputs for creating a good maintenance strategy which can be very simple with execution of sp_updatestats or specialized scripts to focus on some tables.
In high mission-critical environments, ensuring high level of availability is a prerequisite and usually IT department addresses required SLAs (the famous 9’s) with high available architecture solutions. As stated by Wikipedia: availability measurement is subject to some degree of interpretation. Thus, IT department generally focus on uptime metric whereas for other departments availability is often related to application response time or tied to slowness / unresponsiveness complains. The latter is about application throughput and database locks may contribute to reduce it. This is something we are constantly monitoring in addition of the uptime in my company.
A couple of months ago, I experienced a problem about index rebuild online operation on SQL Server. In short, the operation was supposed to be online and to never block concurrent queries. But in fact, it was not the case (or to be more precise, it was partially the case) and to make the scenario more complex, we experienced different behaviors regarding the context. Let’s start the story with the initial context: in my company, we usually go through continuous deployment including SQL modification scripts and because we usually rely on daily pipeline, we must ensure related SQL operations are not too disruptive to avoid impacting the user experience.
A couple of weeks, I read an article from Brent Ozar about using NVARCHAR as a universal parameter. It was a good reminder and from my experience, I confirm this habit has never been a good idea. Although it depends on the context, chances are you will almost find an exception that proves the rule.
I wrote a (dbi services) blog post concerning Linux and SQL Server IO behavior changes before and after SQL Server 2017 CU6. Now, I was looking forward seeing some new improvements with Force Unit Access (FUA) that was implemented with Linux XFS enhancements since the Linux Kernel 4.18.
A couple of days ago, I read the write-up of my former colleague @FranckPachot about refactoring procedural code to SQL. This is recurrent subject in the database world and I was interested in transposing this article to SQL Server because it was about refactoring a Scalar-Valued function to a SQL view. The latter one is a great alternative when it comes performance but something new was shipped with SQL Server 2019 and could address (or at least could mitigate) this recurrent scenario.
Let’s continue with Azure stories and performance scaling …
A couple of weeks ago, we studied opportunities to replace existing clustered indexes (CI) with columnstore indexes (CCI) for some facts. To cut the story short and to focus on the right topic of this write-up, we prepared a creation script for specific CCIs based on the Niko’s technique variation (no MAXDOP = 1 meaning we enable parallelism) in order to get a better segment alignment.
Ceci est mon premier blog de l’année 2018 et depuis un moment d’ailleurs. En effet, l’année dernière j’ai mis toute mon énergie à réajuster mes connaissances Linux avec la nouvelle stratégie Open Source de Microsoft. Mais en même temps, j’ai réalisé un certain nombre de tâches intéressantes chez certains clients et en voici une pour commencer cette nouvelle année. Dans ce billet, j’aimerai souligner une approche particulière (selon moi) pour optimiser une mise à jour de statistiques pour une grosse table.
> Lire la suite (en anglais)
David Barbarin
MVP & MCM SQL Server
Je voudrais partager avec vous un problème intéressant de statistiques que vous pouvez rencontrer avec les réplicas en lecture seule dans une infrastructure de groupe de disponibilités. Pour ceux qui les utilisent pour des besoins de Reporting, continuez la lecture de ce billet car il s’agit d’un problème de comportement de mise à jour de statistiques sur ceux-ci pouvant impliquer un problème d’estimation de cardinalités pouvant avoir de graves conséquences sur les performances de vos requêtes.
> Lire la suite (en anglais)
David Barbarin
MVP & MCM SQL Server
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
