Developpez.com
Accueil
An interesting improvement was announced by the SQL AAD team on Monday 27th July 2020 and concerns the support for Azure AD user creation on behalf of Azure AD Applications for Azure SQL as mentioned to this Microsoft blog post.
Il y a quelques temps j’avais écrit un billet sur les power plans de Windows et l’impact que cela pouvait avoir sur SQL Server. Il y a quelques temps j’ai pu l’observer chez un de mes clients qui souffraient de problèmes de performances de requêtes après avoir acheté un nouveau serveur. Voici ce que nous avons pu voir en comparant deux configurations serveurs différentes.
Locked pages in memory et Instant File Initialization sont deux options de performance utilisés fréquemment avec SQL Server. Pour rappel la première option d’empêcher la pagination du buffer pool de SQL Server par le système d’exploitation et la deuxième permet de réduire considérablement les temps d’allocation de fichier en supprimant la phase de remplissage de zéro des fichiers de bases de données. Ceci n’est valable uniquement que pour les fichiers de données SQL Server. Pour bénéficier de ces deux options de performances il faut octroyer au compte de service SQL Server les privilèges nécessaires. Cependant dans beaucoup de littérature et très certainement par habitude, c’est le compte de domaine utilisé par le service SQL qui bénéficie de ces privilèges dans la plupart des cas. Mais qu’en est-il avec l’apparition des SID de service ?
Ce post s’adresse surtout aux maniaques du travail bien fait 
. Lorsque l’on configure un cluster Windows il arrive bien souvent que le nom d’un des 2 noeuds soit en minuscule. Bien que cela n’ait pas d’incidence (enfin il y avait bien quelques cas où cela posait problème comme par exemple l’installation du service pack 3 de SQL Server 2005 en cluster) on peut vouloir avoir nos deux noms en majuscule dans la console de gestion du cluster.
J’ai déjà eu plusieurs fois à répondre à la question suivante : Sous quel contexte utilisateur s’exécute un travail SQL Server ? Est ce qu’il utilise le compte de service du compte de l’agent ou bien le contexte de son propriétaire ?
Le modèle de sécurité de SQL Server a évolué au cours des différentes versions. Chaque version de SQL Server a amené son lot de nouveautés en même temps que les versions de Windows sur lequel il repose. Avec la venue de Windows Vista, Seven ou Server 2008 il est apparu la notion de SID pour les services Windows. Depuis SQL Server 2008 il est possible d’utiliser cette fonctionnalité offerte par les nouvelles versions du système d’exploitation. Mais qu’est ce que un SID exactement ? A quoi cela peut bien servir ? Quels sont les avantages ?
Pour ceux qui utilisent la DMV sys.dm_db_index_physical_stats depuis la version 2005 de SQL Server ont certainement vu une colonne nommée fragment_count. La documentation Microsoft nous donne la description suivante : Nombre de fragments dans le niveau feuille d’une unité d’allocation IN_ROW_DATA. J’ai déjà eu pas mal de questions à ce sujet car même avec la description fournie nous pouvons avoir du mal à visualiser ce que cette colonne représente exactement et quelle peut être la relation avec la fragmentation des indexes.
Vous avez identifié une table candidate à la compression ? mais vous voulez savoir quelle sera la meilleure méthode de compression ROW ou PAGE. SQL Server met à disposition une procédure stockée sp_estimate_data_compression_savings. Cependant l’exécution de cette dernière permet seulement de savoir le taux de compression pour l’une ou pour l’autre méthode pour une seule partition d’une table à la fois. Le script suivant permet de connaître pour une table donnée quelle est la meilleure méthode de compression à utiliser pour l’ensemble des partitions d’une table sachant qu’une table non partitionnée possède une seule partition.
Suite à une discussion sur le forum je me permets une billet sur comment déplacer les données et index d’une base de données de façon équitable dans plusieurs fichiers d’un même groupe de fichiers. Cette opération peut s’avérer utile dans bien des cas. Un exemple simple est l’ajout d’un axe physique disque sur lequel on veut ajouter un fichier de données et répartir équitablement celles-ci pour bénéficier par la suite de l’algorithme de réparation de SQL Server.
Lorsque l’on effectue une installation de SQL Server par défaut, on se retrouve bien souvent avec le compte prédéfini NT AUTORITHY\LOCALSERVICE comme compte de service pour le service SQLBrowser et cela convient bien dans la plupart des scénarios. Cependant je suis tombé dans un cas où un compte de domaine était nécessaire pour ce service pour pouvoir paramétrer correctement la délégation Kerberos avec une instance nommée SSAS. On retrouve dans la documentation en ligne Microsoft les informations de sécurité nécessaires au bon fonctionnement du service SQLBrowser dans ce contexte sauf que …
© 2000-2020 - www.developpez.com
Partenaire : Hébergement Web
