Le degré maximal de parallélisme (DOP) est une option de configuration avancée de SQL Server qui a fait l'objet de nombreuses questions et a fait l'objet de nombreuses publications. Dans cet article de blog, l'auteur espère apporter des éclaircissements sur ce que fait cette option et comment elle doit être utilisée.

Tout d'abord, l'auteur souhaite dissiper tout doute sur le fait que l'option ci-dessus définit le nombre de processeurs que SQL Server peut utiliser lorsqu'il dessert plusieurs connexions (ou utilisateurs) - ce n'est pas le cas ! Si SQL Server a accès à quatre processeurs inactifs et qu'il est configuré pour utiliser les quatre processeurs, il utilisera les quatre processeurs quel que soit le degré maximal de parallélisme.

Alors, à quoi sert cette option ? Cette option définit le nombre maximal de processeurs que SQL Server peut utiliser pour une seule requête. Si une requête à SQL Server doit renvoyer grand volume données (de nombreux enregistrements), il est parfois judicieux de la paralléliser en la divisant en plusieurs petites requêtes, chacune renvoyant son propre sous-ensemble de lignes. Ainsi, SQL Server peut utiliser plusieurs processeurs, et donc sur des systèmes multiprocesseurs un grand nombre de les enregistrements de la requête entière pourraient potentiellement être renvoyés plus rapidement que sur un système monoprocesseur.

De nombreux critères doivent être pris en compte avant que SQL Server n'invoque le "parallélisme intra-requête" (répartition d'une requête en plusieurs threads), et il est inutile de les détailler ici. Vous pouvez les trouver dans BOL en recherchant "Degré de parallélisme". Il dit que la décision de parallélisation est basée sur la disponibilité de la mémoire pour le processeur et, surtout, sur la disponibilité des processeurs eux-mêmes.

Donc, pourquoi nous devrions envisager d'utiliser cette option parce que la laisser à la valeur par défaut (SQL Server décide lui-même de la parallélisation) peut parfois avoir des effets indésirables. Ces effets ressemblent à ceci :

• Les requêtes parallélisées s'exécutent plus lentement.
• Les temps d'exécution des requêtes peuvent devenir non déterministes, ce qui peut gêner les utilisateurs. Le temps d'exécution peut changer car :
  • Une requête peut parfois paralléliser et parfois non.
  • Une requête peut être bloquée par une requête parallèle si les processeurs étaient auparavant surchargés de travail.

Avant de continuer, l'auteur tient à préciser qu'il n'est pas particulièrement nécessaire de se plonger dans l'organisation interne du parallélisme. Si cela vous intéresse, vous pouvez lire l'article "Traitement des requêtes parallèles" dans Books on Line, où ces informations sont présentées plus en détail. L'auteur estime qu'il n'y a que deux choses importantes à savoir sur l'organisation interne du parallélisme :

1. Les requêtes parallèles peuvent générer plus de threads que spécifié dans l'option "Degré maximal de parallélisme". DOP 4 peut générer plus de douze threads, quatre pour les requêtes et des threads supplémentaires utilisés pour les tris, les threads, les agrégats et les assemblages, etc.
2. Le parallélisme des requêtes peut entraîner différentes attentes SPID avec un type d'attente de CXPACKET ou 0X0200. Cela peut être utilisé pour trouver les SPID qui attendent des opérations parallèles et qui ont le type d'attente : CXPACKET dans sysprocesses. Pour faciliter cette tâche, l'auteur propose d'utiliser la procédure stockée disponible sur son blog : track_waitstats.

Et donc "La requête peut s'exécuter plus lentement lorsqu'elle est parallélisée" pourquoi ?

• Si le système est très faible débit sous-systèmes de disque, alors lors de l'analyse d'une requête, sa décomposition peut prendre plus de temps que sans parallélisme.
• Possible biais de données ou verrous de plage de données pour le processeur, générés par un autre processus utilisé en parallèle et lancé ultérieurement, etc.
• S'il n'y a pas d'index pour le prédicat, cela entraîne une analyse de la table. Une opération parallèle dans une requête peut masquer le fait que la requête s'exécuterait beaucoup plus rapidement avec un plan d'exécution séquentiel et avec l'index correct.

Les effets du parallélisme mentionnés ci-dessus devraient à eux seuls vous conduire à l'idée que la mécanique interne de la parallélisation des requêtes n'est pas adaptée à une utilisation dans les applications OLTP. Il s'agit d'applications pour lesquelles la modification du temps d'exécution des requêtes peut gêner les utilisateurs et pour lesquelles un serveur servant plusieurs utilisateurs en même temps est peu susceptible de choisir un plan d'exécution parallèle en raison des caractéristiques inhérentes au profil de charge de travail du processeur dans ces applications.

Par conséquent, si vous envisagez d'utiliser le parallélisme, il sera probablement nécessaire pour les tâches d'extraction de données (entrepôt de données), l'aide à la décision ou les systèmes de reporting, où il n'y a pas beaucoup de requêtes, mais elles sont assez lourdes et sont exécutées sur un puissant serveur avec une grande quantité de mémoire opérationnelle.

Si vous décidez d'utiliser le parallélisme, quelle valeur devez-vous définir pour DOP ?. C'est une bonne pratique pour ce mécanisme que si vous avez 8 processeurs, réglez DOP = 4 et c'est très probablement le réglage optimal. Cependant, il n'y a aucune garantie que cela fonctionnera de cette façon. Le seul moyen d'en être sûr est de tester différentes valeurs de DOP. En plus de cela, l'auteur a voulu offrir ses conseils empiriques, ne fixez jamais ce nombre à plus de la moitié du nombre de processeurs disponibles. Si l'auteur avait moins de six processeurs, il mettrait DOP à 1, ce qui désactiverait simplement la parallélisation. Il pourrait faire une exception s'il avait une base de données qui ne prend en charge qu'un seul processus utilisateur (certaines technologies de récupération de données ou tâches de reporting), auquel cas, à titre exceptionnel, il serait possible de définir DOP sur 0 (valeur par défaut), ce qui permet à SQL Server de décider de lui-même s'il faut paralléliser une requête.

Avant de terminer l'article, l'auteur a tenu à vous avertir que la création parallèle d'index dépend du nombre que vous définissez pour DOP. Cela signifie que vous voudrez peut-être le modifier au moment de créer ou de recréer des index pour améliorer les performances de cette opération, et bien sûr vous pouvez utiliser l'indicateur MAXDOP dans la requête, ce qui vous permet d'ignorer la valeur définie dans la configuration et peut être utilisé pendant les heures creuses.

Enfin, votre requête peut ralentir lors de la parallélisation en raison d'erreurs, alors assurez-vous d'avoir le dernier service pack installé sur votre serveur.

REATE proc track_waitstats
@num_samples entier = 10
,@delaynum entier = 1
,@delaytype nvarchar ( 10 )="minutes"
COMME
-- T. Davidson
-- Cette procédure stockée est fournie =EN L'ÉTAT= sans aucune garantie,
-- et conférences sans droits.
-- L'utilisation des exemples de script inclus est soumise aux conditions
-- spécifié sur http://www.microsoft.com/info/cpyright.htm
-- @num_samples est le nombre de fois pour capturer les statistiques d'attente,
-- la valeur par défaut est 10 fois. l'intervalle de délai par défaut est de 1 minute
-- delaynum est l'intervalle de retard. delaytype spécifie si
-- l'intervalle de retard est de minutes ou de secondes
-- créer une table waitstats si elle n'existe pas, sinon la tronquer

ne comptez pas sur
s'il n'existe pas (sélectionnez 1 de sysobjects où name = "waitstats" )
créer une table waitstats(varchar( 80 ),
requêtes numériques ( 20 ,1 ),
numérique ( 20 ,1 ),
numérique ( 20 ,1 ),
maintenant datetime par défaut getdate())
sinon tronquer la table waitstats

dbcc sqlperf (waitstats, clear) - efface les waitstats

déclarer @i int
,@delay varchar ( 8 )
,@dt varchar ( 3 )
,@maintenant dateheure
,@totalwait numérique ( 20 ,1 )
,@endtime dateheure
,@begintime dateheure
,@hr entier
,@min entier
,@sec int

sélectionnez @i = 1
sélectionnez @dt = minuscule (@delaytype)
quand "minutes" puis "m"
quand "minute" puis "m"
quand "min" puis "m"
quand "mm" puis "m"
quand "mi" puis "m"
quand "m" puis "m"
quand "secondes" puis "s"
quand "deuxième" puis "s"
quand "sec" puis "s"
quand "ss" puis "s"
quand "s" puis "s"
sinon @delaytype
fin

si @dt pas dans ("s" ,"m" )
commencer
imprimer "veuillez fournir le type de délai, par exemple secondes ou minutes"
retour
fin

si @dt = "s"
commencer
sélectionnez @sec = @delaynum % 60
select @min = cast((@delaynum / 60 ) comme int )
sélectionnez @hr = cast((@min / 60 ) comme int )
sélectionnez @min = @min % 60
fin

si @dt = "m"
commencer
sélectionnez @sec= 0
sélectionnez @min = @delaynum % 60
select @hr = cast((@delaynum / 60 ) comme int )
fin

select @delay = right("0" + convert(varchar( 2 ),@heure), 2 ) + ":" +
2 ),@min), 2 ) + ":" +
+ droite("0" +convertir(varchar( 2 ),@seconde), 2 )

si @hr > 23 ou @min > 59 ou @sec > 59
commencer
sélectionner "hh:mm:ss le délai ne peut pas > 23:59:59"
sélectionnez "intervalle de délai et tapez : " + convert (varchar ( 10 )
,@delaynum) + "," + @delaytype + " convertit en "
+ @retard
retour
fin

alors que je<= @num_samples)
commencer
insérer dans waitstats(, demandes,
,)
exec("dbcc sqlperf(waitstats)" )
sélectionnez @i = @i + 1
attendre le retard @retard
fin

Créer un rapport d'attente
exécuter get_waitstats

--//--//--//--//--//--//--//--//--//-//--//--//--//--//--//--//--//--/

CREATE proc get_waitstats
COMME
-- Cette procédure stockée est fournie =EN L'ÉTAT= sans aucune garantie, et
-- conférences pas de droits.
-- L'utilisation des exemples de script inclus est soumise aux conditions spécifiées
-- sur http://www.microsoft.com/info/cpyright.htm
--
-- cette procédure créera un rapport de statistiques d'attente répertoriant les types d'attente par
-- pourcentage
-- peut être exécuté lorsque track_waitstats est en cours d'exécution

ne comptez pas sur

déclarer @now datetime
,@totalwait numérique ( 20 ,1 )
,@endtime dateheure
,@begintime dateheure
,@hr entier
,@min entier
,@sec int

sélectionnez @now=max (maintenant),@begintime=min (maintenant),@endtime=max (maintenant)
de waitstats où = "Total"

Soustraire waitfor, sleep et resource_queue du total

sélectionnez @totalwait = somme() + 1 à partir des statistiques d'attente
où pas dans ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE"
, "Total" , "***total***" ) et maintenant = @maintenant

Insérer les totaux ajustés, classer par pourcentage décroissant

supprimer les statistiques d'attente où = "***total***" et maintenant = @maintenant

insérer dans les statistiques d'attente sélectionner "***total***"
,0
,@totalwait
,@totalwait
,@maintenant

sélectionner
,
,pourcentage = distribution ( 100 */@totalwait sous forme numérique ( 20 ,1 ))
à partir des statistiques d'attente
où pas dans ("WAITFOR" ,"SLEEP" ,"RESOURCE_QUEUE" ,"Total" )
et maintenant = @maintenant
trier par pourcentage desc

Dans cette courte note, je voudrais parler un peu des subtilités des paramètres de concurrence dans Microsoft SQL Server. Beaucoup d'entre vous connaissent depuis longtemps l'option Max Degree od Parallelism, qui est présente dans SQL Server depuis très longtemps. Par défaut, il est défini sur 0, ce qui signifie que SQL Server choisira lui-même le degré optimal de parallélisme, c'est-à-dire le nombre de processeurs/threads impliqués dans l'exécution d'une instruction. Je ne vais pas m'arrêter maintenant et discuter de la valeur à laquelle il est préférable de définir cette option - c'est un sujet pour une note séparée. Je ne considérerai que la façon dont la valeur de cette option affecte l'exécution des requêtes. Par exemple, dans la figure ci-dessous, cette option est définie sur 1, ce qui signifie que les plans parallèles pour toutes les requêtes sont désactivés par défaut.

Cette option peut également être visualisée avec la commande T-SQL suivante :

En effet, tout plan de requête par défaut sera séquentiel. Par exemple:

Cependant, le développeur et tout utilisateur ont toujours la possibilité d'influencer cela grâce à l'utilisation d'indices. Pour cela, il vous suffit de spécifier le degré de parallélisme souhaité, et le plan de requête souhaité est généré, par exemple :

Et si nous observons cette requête à travers la vue sys.dm_exec_query_profiles, nous verrons qu'elle est bien exécutée en 10 threads.

Ainsi, il reste un trou secret dans le système que les développeurs et les utilisateurs peuvent utiliser pour "accélérer" (ici je le mets spécifiquement entre guillemets, car pas toujours un degré élevé de parallélisme ne conduit pas à une diminution du temps d'exécution des requêtes) leurs requêtes en augmentant le degré de parallélisme. Mais, de cette manière, ils peuvent simplement "tuer" le serveur en lançant de nombreuses requêtes parallèles incontrôlées en même temps. Que pouvons-nous y faire? C'est là que Resource Governor vient à la rescousse, un système très puissant et complètement sous-estimé qui vous permet de répartir les ressources de manière très flexible entre différents groupes d'utilisateurs. Encore une fois, je ne m'attarderai pas sur son fonctionnement et ses capacités. Je vais juste expliquer comment ses paramètres de limite de simultanéité l'affectent. Voyons d'abord les paramètres par défaut :

Encore une fois, nous voyons que l'option est définie sur 0 par défaut et que la décision de choisir le degré maximum est à la merci de SQL Server. Voyons maintenant ce qui se passe si je change cette valeur en 5. Je n'ai même pas défini de fonction de classification pour le gouverneur de ressources et je modifie le groupe par défaut. Mais pour un test et comprendre comment tout fonctionne en ce moment dans mon exemple, cela suffit. Ainsi, je limite le degré maximum de parallélisme pour tout le monde à 5 threads. Rappelons que l'option Degré maximum de parallélisme, que nous avons examiné précédemment, est toujours défini sur 1. Si nous examinons maintenant le plan d'exécution de notre requête d'origine, il sera séquentiel par défaut, et avec l'option maxdop 10, il sera parallèle. Mais, si nous exécutons un plan parallèle, nous verrons quelque chose d'intéressant.

Maintenant, notre requête n'est exécutée que dans 5 threads, malgré le fait que l'option maximum il a une valeur de 10. Et, si vous spécifiez l'option maxdop 4 pour la requête, elle sera exécutée dans 4 threads (l'option dans Resource Governor est définie sur 5). Dans ce cas, l'indice maximum inférieur au paramètre du gouverneur de ressources, aucune restriction supplémentaire n'est donc imposée. Je n'en donne plus d'exemple.

Ainsi, Resource Governor est un outil plus puissant qui limite déjà vraiment le degré maximum de parallélisme pour les requêtes, et ce degré peut être défini différemment pour différents groupes d'utilisateurs. Dans le même temps, l'option Degré maximum de parallélisme fonctionne toujours et fait sa part (ou confond légèrement les administrateurs, les développeurs et les utilisateurs lorsqu'il est associé au gouverneur de ressources). De plus, les options de réglage des valeurs de ces 2 paramètres ne sont limitées que par votre imagination, mais il est important de ne retenir que deux choses : Degré maximum de parallélisme et allusion maximum pour une requête affecte le plan qui sera généré, le nombre maximum de threads qui seront possibles pour cette requête, et le gouverneur de ressources limite davantage la requête d'en haut déjà au moment de l'exécution.

Cible:étudier l'impact du parallélisme SQL sur le travail avec des requêtes 1C

Littérature:

Environnement d'essai :

Windows Server 2008 R2 Entreprise

MS SQL Server 2008 R2

1C Entreprise 8.2.19.90

Figure 1. Propriétés SQL "Général"

Figure 2. Propriétés SQL "Avancé"

Outils:

Profileur de serveur SQL

Interroger la console 1C

Demande d'essai :

CHOISIR

AK.Nom AS Nom

DEPUIS

Registre d'informations Classificateur d'adresses AS AK

JOINTURE INTERNE Registre d'informations Classificateur d'adresses AS AK1

SW AK.Code = AK1.Code

Préparation:

Nous démarrons SQL Server Profiler, établissons une connexion, marquons les événements et les colonnes comme illustré à la figure 3.

Figure 3. Propriétés de trace

Mise en place de la sélection pour notre base

Figure 4. Filtrer par base de données

Abréviations :

Degré maximum de parallélisme – MDOP

Seuil de coût pour le parallélisme - coût

Tester un plan de requête séquentiel (MDOP = 1)

Figure 5. Console de requête - temps d'exécution de 20 secondes

Le paramètre du serveur SQL « Degré maximal de parallélisme » est défini sur 1 (pas de parallélisme). Nous regardons le résultat dans le profileur (Fig. 6)

Figure 6. Plan de requête séquentiel

Le serveur SQL a généré un plan de requête séquentiel, tandis que : charge CPU totale = 6,750 (sec) et temps d'exécution de la requête = 7,097 (sec)

Test du plan de requête parallèle (MDOP = 0, coût = 5)

On met le serveur SQL en mode parallélisme (dans SQL Query) :

UTILISER maître ;

EXEC sp_configure "afficher l'option avancée" , 1;

RECONFIGURER AVEC OVERRIDE

UTILISER maître ;

exec sp_configure "degré maximum de parallélisme" , 0;

RECONFIGURER AVEC OVERRIDE

Exécution de la même requête (Figure 7)

Figure 7. Console de requête - temps d'exécution de 16 secondes

Vérification du résultat dans le profileur (Figure 8)

Figure 8. Plan de requête parallèle

Le serveur SQL a cette fois formé un plan de requête parallèle, avec la charge CPU totale = 7,905 secondes et la durée de la requête = 3,458 secondes

Tester un plan de requête séquentiel (MDOP = 0, coût = 150)

Essayons de nous débarrasser du plan parallèle en utilisant le paramètre "Seuil de coût pour le parallélisme". Par défaut, le paramètre est fixé à 5. Dans notre cas, nous avons réussi à nous débarrasser de la formation d'un plan parallèle avec une valeur de 150 (en SQL Query) :

UTILISER maître ;

exec sp_configure "seuil de coût pour le parallélisme", 150 ;

On vérifie l'exécution de la requête dans ces conditions (Fig. 9)

Figure 9. Console de requête - temps d'exécution de 20 secondes

Nous vérifions le résultat dans le profileur (Fig. 10)

Figure 10. Plan de requête séquentiel.

SQL Server a généré un plan de requête séquentiel. Utilisation totale du CPU = 7,171 s, temps d'exécution de la requête = 7,864 s.

Conclusion :

L'exécution d'une requête de test dans l'environnement 1C Enterprise à l'aide d'un plan de requête parallèle SQL Server donne une amélioration significative des performances par rapport à un plan séquentiel (16 sec. contre 20 sec. - gain de 4 sec.)

L'exécution des requêtes de test par SQL Server lui-même lors de l'utilisation d'un plan de requête parallèle est deux fois plus rapide que lors de l'utilisation d'un plan de requête série (3,5 secondes contre 7,1 secondes)

Le parallélisme du serveur SQL peut être ajusté non seulement à l'aide du paramètre MDOP, mais également du paramètre "Сost threshold for parallelism"

• Didacticiel

Ce guide est destiné aux débutants à la recherche d'un guide simple en russe pour installer la version anglaise de SQL Server 2012, qui sera utilisée pour SharePoint 2013.
Cet article n'est pas destiné aux professionnels.

Tout le travail est divisé en 3 étapes:

• Installation de SQL Server 2012
• Définition de l'option de configuration du serveur Degré maximal de parallélisme
• Configuration des droits du compte destiné à installer SharePoint 2013

L'article décrit également le processus d'installation de Microsoft .NET Framework 3.5 sur MS Windows Server 2012 R2 Standard.

Attention : il y a beaucoup de photos sous la coupe !

Installation de SQL Server 2012

1. Avant l'installation, vous devez vous assurer qu'il y a suffisamment d'espace libre sur votre disque dur (dans mon cas, il a fallu 2,7 Go).
Après avoir démarré le kit de distribution, sélectionnez l'élément " Installation" dans le menu de gauche, puis " cliquez sur " l'item " Nouveau SQL Server autonome ou ajouter des fonctionnalités à une installation existante":

2. L'assistant d'installation démarre. Il vérifiera. Vous pouvez cliquer sur le bouton "Afficher les détails" et voir un rapport détaillé :

3. Rapport détaillé. Appuyez sur le bouton "OK":

4. Saisissez la clé de produit et cliquez sur le bouton "Suivant" :

5. Nous sommes d'accord avec les termes du contrat de licence.
Pour cela, cochez la case J'accepte les conditions d'utilisation

6. À l'étape "Configurer le rôle", sélectionnez le premier élément " Installation de la fonctionnalité SQL Server". Appuyez sur le bouton "Suivant":

7. À l'étape "Sélection des fonctionnalités", cochez " Services de moteur de base de données", "Outils de gestion de base" Et " Outils de gestion - Complet". Cliquez ensuite sur le bouton "Suivant":

8. L'installateur effectuera alors une autre vérification. Vous pouvez cliquer sur le bouton "Afficher les détails" et voir un rapport détaillé :

9. Rapport détaillé. (A ce stade, j'ai eu une erreur dans la règle "Microsoft .NET Framework 3.5 est installé ...". Plus d'informations ci-dessous). Appuyez sur le bouton "Suivant":

10. A l'étape "Configuration de l'instance", vous devez configurer l'instance du service SQL Server.
Encore une fois, cet article est destiné aux débutants. Par conséquent, nous supposerons que SQL Server n'a pas été installé sur votre serveur auparavant, ce qui signifie que nous laisserons tous les paramètres par défaut. Appuyez sur le bouton "Suivant":

11. Dans cette étape, l'assistant d'installation affichera les besoins en espace disque. Appuyez sur le bouton "Suivant":

12. A l'étape "Configuration du serveur", vous devez spécifier un compte de domaine pour le service " Moteur de base de données SQL Server". Après avoir renseigné les champs "Nom du compte" et "Mot de passe", cliquez sur le bouton "Suivant" :

13. A l'étape "Database Engine Configuration", il suffit d'ajouter l'utilisateur courant aux administrateurs du serveur SQL. Pour cela, cliquez sur le bouton « Ajouter un utilisateur actuel », puis cliquez sur le bouton « Suivant » :

14. A l'étape suivante, cliquez sur le bouton "Suivant":

15. Ensuite, l'assistant d'installation effectuera à nouveau le test et affichera ses résultats. Appuyez sur le bouton "Suivant":

16. À l'étape "Prêt à installer", l'assistant affichera des informations récapitulatives. Ici, vous devez cliquer sur le bouton "Installer":

17. Une fois l'installation terminée, des informations sur les opérations effectuées s'affichent :

18. Je vous recommande fortement de redémarrer votre ordinateur à ce stade. Dans certains cas (par exemple, lors de l'installation de Microsoft .NET Framework 3.5), l'assistant d'installation lui-même affichera une fenêtre vous invitant à redémarrer l'ordinateur. N'abandonnez pas.

Définition de l'option de configuration du serveur Degré maximal de parallélisme

La valeur par défaut du paramètre "Degré max de parallélisme" est 0.
SharePoint 2013 requiert que ce paramètre soit 1.
C'est facile à réparer !

1. Courir Microsoft SQL Server Management Studio(Démarrer - Tous les programmes - Microsoft SQL Server 2012 - SQL Server Management Studio).

2. Sur l'écran de connexion au serveur, cliquez sur le bouton Connecter.

3. Faites un clic droit sur votre serveur dans le " Explorateur d'objets" et sélectionnez " Propriétés":

4. Dans la fenêtre des propriétés du serveur qui s'ouvre, dans le menu de gauche, sélectionnez la page " Avancé" et faites défiler la liste des propriétés tout en bas de l'écran. Réglez la valeur du paramètre " Degré maximum de parallélisme"V 1 et cliquez sur le bouton "OK":

5. Ne fermez pas SQL Server Management Studio, nous en aurons toujours besoin.

Configuration des droits du compte destiné à installer SharePoint 2013

Le compte sous lequel SharePoint 2013 sera installé doit être élevé dans SQL Server.
Il est recommandé d'attribuer à ce compte les rôles suivants :

• créateur de base de données
• administrateur de sécurité
• public

1. Dans SQL Server Management Studio, dans le " Explorateur d'objets"développer l'élément" Sécurité". Ensuite, faites un clic droit sur le " Connexions" et sélectionnez " Nouvelle connexion":

2. Dans le champ "Nom de connexion", entrez le nom de domaine du compte sous lequel vous envisagez d'installer et de configurer SharePoint 2013.

3. Dans le menu de gauche, sélectionnez la page " Rôles de serveur" et cochez les rôles "dbcreator" et "securityadmin", et assurez-vous que le rôle "public" est déjà coché. Cliquez ensuite sur le bouton "OK":

SQL Server est maintenant prêt à installer SharePoint 2013.

Installation de Microsoft .NET Framework 3.5 sur MS Windows Server 2012 R2 Standard

A l'étape numéro 9 du paragraphe " Installation de SQL Server 2012" J'ai une erreur : .NET Framework 3.5 n'a pas été installé.
Pour résoudre ce problème, procédez comme suit :

1. Vous devez ouvrir la console " gestionnaire de serveur".

2. Dans le menu de gauche, sélectionnez l'élément "Tableau de bord".

3. Au centre de la fenêtre, cliquez sur l'élément "Ajouter des rôles et des fonctionnalités".

4. Dans l'assistant qui s'ouvre, ignorez l'étape « Avant de commencer ».

5. À l'étape "Type d'installation", sélectionnez " Installation basée sur les rôles ou les fonctionnalités". Appuyez sur le bouton "Suivant".

6. À l'étape suivante, laissez tout par défaut et cliquez sur le bouton "Suivant".

7. Ignorez l'étape "Server Roles" en cliquant sur le bouton "Next".

8. A l'étape "Fonctionnalités", cochez la case "Fonctionnalités .NET Framework 3.5". Nous appuyons sur le bouton "Suivant".

9. Une fois le processus d'installation terminé, vous pouvez fermer l'assistant d'ajout de rôles et de fonctionnalités.

10. C'est fait !

Tout bon et paisible ciel au dessus de ta tête !

PS Bonne journée de l'astronautique !

Cet article se concentrera uniquement sur MS SQL Server. Si vous allez "tenter votre chance" en utilisant 1C avec Oracle, DB2, Postrgre, cette information vous sera inutile. Mais vous devez comprendre que dans 1C, il y a avant tout des spécialistes de MS SQL Server. Grâce aux efforts d'IBM, il existe également des spécialistes DB2. Vous pouvez parler longtemps de bon ou de mauvais SGBD, une chose est importante, le 1C le plus "fluide" fonctionne avec le serveur MS SQL. A en juger par les derniers messages du "front", le travail avec DB2 est devenu plus ou moins décent. Bien que j'aie personnellement eu l'expérience de configurer 1C pour qu'il fonctionne avec DB2 dans la version 8.1, tout n'était pas très bon là-bas. Dans tous les cas, le choix d'un autre SGBD doit être clairement argumenté - soit par les possibilités qui ne sont pas dans MS SQL (un cluster avec load balancing, Grid, etc.), soit par les finances (Oracle a déjà été racheté), soit par la plateforme (tout est sous linux).

Donc, dans l'ordre, que faut-il faire avec MS SQL Server :

1) Réglez la mémoire minimale et maximale. Le minimum est la moitié de la mémoire système. Maximum - mémoire système sans 2 Go. Cela se fait via Management Studio - dans les propriétés du serveur :

2) Si la priorité n'est pas définie dans l'onglet "Processeurs", vous devez définir

3) Réglez le degré maximum de parallélisme sur 1.

4) Activez SQL Server Agent, configurez Database Mail - il n'y a rien de difficile là-bas, je ne décrirai pas en détail.

5) Configurez les forfaits :
Sont communs:
a) Mise à jour des statistiques - toutes les 2 heures
b) DBCC FREEPROCCACHE - toutes les 2 heures
Pour chaque socle :
a) Sauvegarde complète
b) Sauvegarde différentielle
c) Défragmentation d'index - tous les jours
d) Reconstruction de l'index - nuits de week-end
e) Vérification de l'intégrité de la base de données - une fois par mois la nuit le week-end

6) Je recommande de définir le modèle de récupération sur Simple pour chaque base de données (dans les propriétés). Si vous n'avez pas de système 24h/24 et 7j/7 et moins de 1000 utilisateurs par base de données, qu'il n'y a pas de cluster de basculement et que vous n'avez pas signé de SLA dans lequel vous vous engagez à restaurer les données à la seconde près en cas de panne d'un équipement (et pas à partir de la dernière sauvegarde), cette recommandation serait raisonnable. Sinon, vous allez très bientôt réfléchir longuement et frénétiquement où mettre le journal Tranzaction envahi

7) Supprimez la base de données tempdb des bases de données régulières sur un autre disque - même si cela signifie reconfigurer la matrice RAID et dégrader ses performances. Sinon, 1 utilisateur pourra paralyser le travail de tous les autres. Si vous avez un accélérateur matériel au lieu d'un disque dur, vous ne pouvez bien sûr pas le séparer et y mettre tempdb, mais ce n'est que s'il y en a un

8) installer un outil de surveillance - j'aime Spotlight http://www.quest.com/spotlight-on-sql-server-enterprise/ par exemple

9) Testez-vous avec l'analyseur des meilleures pratiques de Microsoft - http://www.microsoft.com/download/en/details.aspx?id=15289 - un excellent outil qui aide non seulement avec les paramètres, mais aussi avec la résolution de nombreux problèmes.

Maintenant, en un mot, pourquoi nous avons fait tout cela :

1) Mémoire. La valeur minimale vous évitera simplement des "problèmes" lorsque le serveur SQL, pour une raison connue de lui seul, n'utilise pas toute la mémoire dont il dispose. Faut tout manger ! La valeur maximale vous évitera de permuter si le même optimiseur d'utilisation de la mémoire du serveur SQL décide que cela ne ferait pas de mal ....

3) Un point très important - IHMO il doit être mis à 1 dans tous les systèmes transactionnels. Tout d'abord, cela empêche certains des verrous entre différents processus essayant d'exécuter 1 requête, et nous évite par conséquent des erreurs "étranges". Deuxièmement... 1 requête "tuée" pourra prendre en charge toutes les ressources du serveur, ce qui est quelque peu injuste par rapport aux autres utilisateurs du système. Le paramètre lui-même détermine combien de cœurs de processeur peuvent traiter 1 requête.

5) A propos des statistiques et de l'effacement du cache procédural - c'est "à l'oreille" mais nous oublions souvent la réindexation. Pendant ce temps, cette procédure est assez importante, surtout avec la croissance du volume de la base de données, son importance augmente. Parfois, jusqu'à 60 % des performances sont perdues lors de la fragmentation des index.

7) Si vous avez un accélérateur matériel ou seulement 2 disques avec des vitesses d'accès différentes, je recommanderais également de penser à allouer des groupes de fichiers dans les bases de données et à diviser les tables individuelles en différentes baies de disques avec des temps d'accès différents. Après tout, vous conviendrez que le PH "marchandises en entrepôts" et l'ouvrage de référence "Stockage d'informations complémentaires" sont 2 objets dont les exigences de stockage sont fondamentalement différentes. Il n'est pas nécessaire de stocker tous les fichiers et images de la base de données sur un tableau rapide - vous pouvez le séparer en un tableau séparé, pas si rapide, mais où il y a beaucoup d'espace (et ne pas avoir peur de télécharger un tas de fichiers dans la base de données plus tard, soit dit en passant).