Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Le champ CountryOrRegion génére un filtre OPATH invalide dans une liste de distribution dynamique

par | 15 Juin 2017 | , ,

Problème:

Impossible de requêter les membres d’un groupe dynamique Exchange ayant un paramètre de filtrage sur le champ « CountryOrRegion ».

L’erreur spécifiée est générique et indique que le filtre OPATH ou LDAP est invalide:

« La chaîne de filtre de prévisualisation du destinataire $VotreFiltre n’est ni un filtre OPath valide ni un filtre LDAP valide. Utilisez le paramètre -RecipientPreviewFilter avec une chaîne de filtre OPath valide ou une chaîne de filtre LDAP valide. »

Cause:

Une des raisons possible à ce message d’erreur est que la valeur du champ CountryOrRegion ait été déclarée depuis une console Powershell en français (ou toute langue autre que l’anglais). En effet la console powershell interprète et traduit directement la valeur spécifiée pour l’attribut CountryOrRegion.

Par exemple, si vous spécifiez la valeur « CountryOrRegion -eq Germany » ou « CountryOrRegion -eq DE » et que votre console powershell est en français, la valeur retenue et transmise dans le filtre OPATH sera « CountryOrRegion -eq Allemagne ».

Ceci est problématique car les serveurs Exchange installés en anglais seront incapables de traduire cette valeur et vous ne pourrez pas interagir avec cette liste de distribution dynamique pour la partie modification et récupération des membres, la liste en elle-même devrait normalement être fonctionnelle. 

Autre raison possible, la valeur n’est pas renseignée correctement.

Les valeurs doivent correspondre à la norme ISO 3166-1 de l’appellation des pays.

https://fr.wikipedia.org/wiki/ISO_3166-1

Solution:

Actuellement, ce problème est considéré comme un fonctionnement standard du produit, pour corriger les listes de distributions dynamiques en erreur, il vous faudra les recréer depuis une console en anglais.

 

 

SQL Server–Optimiser les paramètre d’exécution parallèle (1/2)

par | 13 Juin 2017 | ,

Introduction :

SQL Server est conçu pour optimiser l’exécution des requêtes de manière transparente, l’une des méthodes utilisé par SQL est le calcul parallélisé de requêtes.

Cette méthode d’optimisation consiste à diviser l’exécution d’une requête à travers threads afin d’accélérer l’exécution de la requête.

Ce post composé de deux parties à pour objectif de présenter les paramètres suivants :

  • MAXDOP (partie 1/2),
  • Cost Threshold for Parallelism (partie 2/2)

Explication :

Le paramètre MAXDOP signifie “Max Degree of Parallelism”, ce paramètre permet de maitriser le nombre maximum de processeurs pouvant intervenir dans l’exécution d’une requête parallélisée, il est important de comprendre que ce paramètre ne peut être utilisé pour limiter le nombre de processeurs utilisés par SQL.

Ce lien liste les valeur recommandées par Microsoft afin de paramétrer cette valeur en fonction des versions de SQL Serveur, ce lien peut également être utilisé pour calculer la valeur optimale à positionner. Il est bien entendu nécessaire de tester les différentes configurations en fonction de la charge soumise par l’application qui utilise le serveur SQL.

Réalisation

Le paramètre MAXDOP peut être modifié depuis les propriétés de l’instance SQL concernée dans la partie Advanced->Parallelism :

image

Ou via la requête suivante (en remplaçant VALEUR par la valeur désirée) :

sp_configure ‘show advanced options’, 1;
GO
RECONFIGURE;
GO
dbo.sp_configure ‘max degree of parallelism’, VALEUR;
GO

RECONFIGURE;
GO

La modification du paramètre MAXDOP est prise en compte sans qu’il n’y a à redémarrerredemmarer l’instance.

Sources :

SQL Server–Optimiser les paramètre d’exécution parallèle (2/2)

par | 13 Juin 2017 | ,

Introduction :

Comme vu dans le post précèdent, SQL Server dans sa configuration par défaut optimise automatiquement l’exécution des requêtes, notamment en répartissant son exécution à travers différents threads.

Ce post composé de deux parties à pour objectif de présenter les paramètres suivants :

  • MAXDOP (partie 1/2),
  • Cost Threshold for Parallelism (partie 2/2)

La partie 2/2 de ce post auras pour objectif de configurer SQL afin que seules les requêtes considérées comme volumineuses ne soient traitées en parallèle.

Explication :

Le paramètre “Count Threshold for Parallelism” permet à SQL de ne paralléliser que les requêtes dont le coût d’exécution d’un plan en série (mesuré en secondes) serait plus élevé que la valeur définie.

L’optimisation réalisée par SQL, bien qu’efficace pour les requêtes “volumineuses”, peut se révéler désastreuse pour l’exécution concurrente d’un grand nombre de petites requêtes, il est donc judicieux de revoir la valeur de ce paramètre en fonction du type de charge exercée sur le serveur SQL.

En règle générale, une valeur comprise entre 20 et 50 est un bon début qui doit être affiné par des tests spécifiques à l’application.

Par défaut, la valeur du paramètre “Count Threshold for Parallelism” est de 5, cette valeur provient du temps nécessaire à l’exécution d’une requête sur le poste de “Nick” un employé de Microsoft membre de l’équipe Query Optimizer lorsque le Query Optimizer était en cours de développement pour SQL Server 7.

Nick devait – entre autre – développer la méthode de calcul du coût d’une requête, il a donc utilisé son ordinateur comme étalon, depuis, le coût d’exécution d’une requête estimé par SQL est….le temps d’exécution qu’aurais pris la machine de Nick.

Bien entendu, les machines utilisées ne sont plus les mêmes et les temps d’exécutions sont donc plus courts :

image

La machine de Nick.

SQL Server ignore la valeur de l’option cost threshold for parallelism dans les cas suivants :

  • L’ordinateur ne dispose que d’un seul processeur.
  • Un seul UC est disponible pour SQL Server en raison de l’option de configuration affinity mask.
  • L’option max degree of parallelism a la valeur 1.

 

Réalisation

Le paramètre Count Threshold for Parallelism peut être modifié depuis les propriétés de l’instance SQL concernée dans la partie Advanced->Parallelism :

image

Ou via la requête suivante (en remplaçant VALEUR par la valeur désirée) :

sp_configure ‘show advanced options’, 1;
GO
reconfigure;
GO
sp_configure ‘cost threshold for parallelism’, VALEUR;
GO
reconfigure;
GO

La modification du paramètre Count Threshold for Parallelism est prise en compte sans qu’il n’y a à redémarrer l’instance.

Sources :

Derniers articles

Catégories

Archives

Auteurs/Autrices