Exigences du sous-système d'e/s de Microsoft SQL Server pour la base de données tempdb

IMPORTANT : Cet article est issu d'une traduction automatique réalisée par un logiciel Microsoft et non par un traducteur professionnel. Cette traduction automatique a pu aussi être révisée par la communauté Microsoft grâce à la technologie Community Translation Framework (CTF). Pour en savoir plus sur cette technologie, veuillez consulter la page http://support.microsoft.com/gp/machine-translation-corrections/fr. Microsoft vous propose en effet des articles traduits par des professionnels, des articles issus de traductions automatiques et des articles issus de traductions automatiques révisées par la communauté Microsoft, de manière à ce que vous ayez accès à tous les articles de notre Base de connaissances dans votre langue. Il est important de noter que les articles issus de la traduction automatique, y compris ceux révisés par la communauté Microsoft, peuvent contenir des erreurs de vocabulaire, de syntaxe ou de grammaire. Microsoft ne pourra être tenu responsable des imprécisions, erreurs, ainsi que de tout dommage résultant d’une traduction incorrecte du contenu ou de son utilisation par les clients.

La version anglaise de cet article est la suivante: 917047
Résumé
Microsoft SQL Server nécessite que le sous-système d'e/s utilisé pour stocker des bases de données système et utilisateur entièrement respectent les exigences de Write-Ahead Logging (WAL) par l'intermédiaire des entités d'e/s spécifiques. Ces exigences sont nécessaires pour honorer les propriétés ACID des transactions : atomique, cohérente, isolée et Durable. Plus d'informations sur les exigences de conformité du sous-système d'e/s sont fournis dans les références suivantes :La liste suivante est un résumé rapide de la configuration requise :
  • Ordre d'écriture doit être maintenue.
  • Cohérence des écritures dépendantes doit être maintenue.
  • Écritures doivent toujours être sécurisés dans/sur un support stable.
  • Déchirée prévention d'e/s doit se produire.
Maintenance de durabilité reste essentiel pour toutes les autres bases de données, mais peut être assouplie pour la base de données tempdb . Le tableau suivant résume plusieurs des exigences d'e/s critiques pour les bases de données SQL Server.
Demande d'e/sBrève descriptionSystème ou utilisateurtempdb
Écrire des commandes

Cohérence des écritures dépendantes
La capacité du sous-système de maintenir l'ordre correct des opérations d'écriture. Cela peut être particulièrement important pour la mise en miroir des solutions, les exigences de cohérence de groupe et l'utilisation du protocole WAL de SQL Server.RequisRecommandé
Lecture après écritureLa capacité du sous-système au service les requêtes avec la dernières données image de lecture lorsque la lecture est émise après que toute écriture est effectuée avec succès.RequisRequis
Survie sur panneLa possibilité pour les données restent entièrement intacts (durables) entre une panne, par exemple un système de redémarrer.RequisNe s'applique pas
Prévention des e/s déchiréeLa capacité du système pour éviter de fractionner les demandes d'e/s individuelles.RequisRecommandé
Réécriture de secteurLe secteur peut uniquement être écrit dans son intégralité et ne peut pas être réécrite en raison d'une demande d'écriture sur un secteur à proximité.* Déconseillée, uniquement autorisés si transactionnelle* Déconseillée, uniquement autorisés si transactionnelle
Sécurité renforcée des donnéesL'attente que lorsqu'une demande d'écriture ou une opération FlushFileBuffers est terminée, les données ont été enregistrées sur un support stable.RequisNe s'applique pas
Taille et l'alignement de secteur physiqueSQL Server interroge les emplacements de stockage des fichiers journaux et de données. Tous les périphériques sont nécessaires pour prendre en charge les attributs de secteur permettant de SQL Server pour effectuer des écritures sur des limites physiques aligné sur le secteur et d'un multiple de la taille de secteur.RequisRequis
* Réécritures secteur transactionnelle impliquent des opérations entièrement consignées par le sous-système autorisant un secteur à être entièrement déplacé, remplacé ou restaurée à l'image d'origine. Ces réécritures sont généralement déconseillés en raison des temps de traitement requis pour effectuer des actions supplémentaires. Un exemple de cela est un utilitaire de défragmentation qui déplace les données du fichier. Impossible de remplacer le secteur d'origine dans le fichier avec le nouvel emplacement de secteur jusqu'à ce que le nouveau secteur et les données sont entièrement sécurisées. Le remappage du secteur doit se produire de manière transactionnelle afin que tout échec, y compris une panne de courant, entraîne le rétablissement des données d'origine. Assurez-vous que vous disposez de mécanismes de verrouillage disponibles au cours de ce genre de processus afin d'empêcher l'accès aux données non valides, bas ainsi les autres locataires d'e/s de SQL Server.

Survie sur panne

Un plan de montage pour SQL Server et la base de données tempdb est reconstruite à chaque démarrage de SQL Server. L'initialisation remplace n'importe quel besoin en données de résister à un redémarrage.

Opérations de réécriture secteur transactionnelle

Pour garantir le succès du processus de récupération, tel que la récupération sur incident et de restauration, les enregistrements du journal doivent être correctement stockés sur un support stable avant que la page de données est stockée et ne peut pas être réécrite sans en respectant les propriétés transactionnelles. Cela nécessite le sous-système et SQL Server pour mettre à jour les attributs spécifiques, tels que de l'ordre d'écriture, secteur alignés et dimensionnés écrit et autres ces attributs de sécurité d'e/s indiquées dans les documents mentionnés précédemment. La base de données tempdb , la récupération après incident n'est pas nécessaire, car la base de données est toujours initialisée lors du démarrage de SQL Server. Toutefois, la base de données tempdb nécessite toujours des possibilités de retour. Par conséquent, certains attributs du protocole WAL peuvent être assouplies.

L'emplacement de stockage pour la base de données tempdb doit agir en stricte conformité avec les protocoles de disque établies. Dans tous les cas, le périphérique sur lequel est stockée la base de données tempdb doit apparaître et d'agir comme un disque physique fournissant la lecture après les capacités d'écriture. Opérations de réécriture de secteur de transaction peuvent être une exigence supplémentaire des implémentations spécifiques. Par exemple, SQL Server ne gère pas les modifications à l'aide de compression du système de fichiers NTFS car la compression NTFS peut être réécrites secteurs du journal qui ont déjà été écrit et considéré comme renforcées de la base de données. Une défaillance au cours de ce type de réécriture peut provoquer inutilisable, endommage les données de la base de données que SQL Server déjà considéré comme sécurisé.

Remarque SQL Server 2005 étendu de compression ou prise en charge pour lire uniquement les bases de données et groupes de fichiers. Consultez le SQL Server 2005 Books Online pour plus de détails.

Opérations de réécriture secteur transactionnelle sont rapportent à toutes les bases de données SQL Server qui incluent la base de données tempdb . Une diversité croissante des technologies de stockage étendu utilisent des périphériques et utilitaires qui peuvent réécrire des données de SQL Server estime sécurisé. Par exemple, certaines des technologies émergentes effectuent en mémoire cache ou la compression de données. Afin d'éviter des dommages graves de la base de données, une réécriture de secteur doit être prise en charge transactionnelle complète de telle sorte que si une défaillance se produit, les données sont restaurées vers les images de secteur précédente. Cela garantit que SQL Server n'est jamais exposée à une interruption inattendue ou condition de dommages de données.

Vous ne pourrez pas placer la base de données tempdb sur des sous-systèmes spécialisés, tels que des disques virtuels, à l'état solide ou autres mises en œuvre à grande vitesse qui ne peut pas être utilisés pour d'autres bases de données. Toutefois, les facteurs clés présentés dans la section « Informations supplémentaires » prendre en considération lors de l'évaluation de ces options.
Plus d'informations
Plusieurs facteurs doivent être étudiées avec soin lorsque vous évaluez l'emplacement de stockage de la base de données tempdb . Par exemple, l'utilisation de la base de données tempdb implique, mais n'est pas limitée à, faible encombrement mémoire, le plan de requête et décisions d'e/s. Le réglage approprié et la mise en oeuvre de la base de données tempdb peuvent améliorer l'évolutivité et la réactivité d'un système. Cette section explique les facteurs déterminants pour déterminer les besoins en stockage de la base de données tempdb .

Sous-systèmes à grande vitesse

Diverses implémentations de sous-système haute vitesse sont disponibles sur le marché qui fournissent des exigences relatives au protocole sous-système e/s de SQL Server mais qui ne fournissent pas de durabilité du support.

Important Toujours confirmer avec le fabricant du produit afin de garantir le plein respect des besoins d'e/s de SQL Server.

Un disque virtuel est un exemple courant d'une telle implémentation. Les disques RAM installer les pilotes nécessaires et activer partie du disque RAM principal s'affiche en tant qu'et fonctionne comme n'importe quel lecteur de disque qui est connecté au système. Tous les sous-systèmes d'e/s doivent fournir la pleine conformité avec les exigences d'e/s de SQL Server. Toutefois, il est évident qu'un disque RAM n'est pas support durable. Par conséquent, une implémentation telle qu'un disque virtuel peut uniquement être utilisée comme l'emplacement de la base de données de tempdb et ne peut pas être utilisée pour toute autre base de données.

Clés à prendre en compte avant la mise en œuvre et de déploiement

Il y a différents points à prendre en compte avant le déploiement de la base de données tempdb sur ce type de sous-système. Cette section utilise un disque RAM comme base de discussion, mais les résultats similaires se produisent dans d'autres implémentations à grande vitesse.

Sécurité d'e/s

Conformité de lecture après écriture et écrit de secteur transactionnelle est indispensable. Jamais déployer SQL Server sur un système qui ne prend pas entièrement en charge les exigences d'e/s de SQL Server, ou vous risquez de dommages et la perte de vos données.

Pages déjà mise en cache (cache RAM Double)

Les tables temporaires sont comme toutes les autres tables dans une base de données. Ils sont mis en cache par le pool de tampons et gérés par les opérations d'écriture différée. Stockage de pages de table temporaire sur un disque virtuel entraîne la RAM double mise en mémoire cache dans le pool de tampons et l'autre sur le disque RAM. Cette taille totale du pool de mémoire tampon prend directement et généralement diminue les performances de SQL Server.

Abandonner la RAM

Le disque RAM désigne une partie de la mémoire RAM principale, comme son nom l'indique. Il existe plusieurs implémentations de disques RAM et les caches de fichiers basés sur la mémoire vive disponible. Certains permettent également d'e/s physiques, les opérations de sauvegarde. L'élément clé du cache du fichier de base de RAM est qu'il prend directement la mémoire physique qui peut être utilisée par SQL Server. Toujours avoir une preuve évidente que l'ajout un cache de fichier basé sur la mémoire vive améliore les performances de l'application et ne diminue pas des performances de la requête ou de l'application.

Tout d'abord de régler

Une application doit régler pour supprimer les hachages qui pourraient entraîner l'utilisation de la base de données tempdb et les tris inutiles et indésirables. Nombre de fois où l'ajout d'un index peut supprimer la nécessité de tri ou de hachage dans le plan complètement, conduisant à des performances optimales sans exiger l'utilisation de la base de données tempdb .

Avantage possible de points

Les avantages de l'utilisation de la base de données tempdb sur un système à grande vitesse ne peuvent être déterminées grâce à des tests rigoureux et mesures des charges de travail d'application. La charge de travail doit être étudiée avec soin les caractéristiques qui peut-être bénéficier de la base de données tempdb et la sécurité d'e/s doit être confirmée avant le déploiement.

Les opérations de tri et de hachage fonctionnent avec les gestionnaires de mémoire de SQL Server pour déterminer la taille de la zone de travail en mémoire pour chaque opération de tri ou de hachage. Dès que les données de tri ou de hachage dépassent le plan de montage de mémoire alloué, les données peuvent être écrites dans la base de données tempdb . Cet algorithme a été développé dans SQL Server 2005, ce qui réduit les demandes d'utilisation de base de données tempdb sur des versions antérieures de SQL Server. Par exemple, en utilisant un tri pur forcé d'une table, sans index, l'ordre décroissant et la même configuration matérielle, SQL Server 2005 montre une amélioration notable par rapport à SQL Server 2000.

Attention SQL Server est conçu pour prendre en compte les niveaux de mémoire et les activités de requête en cours lors de la prise de décisions de plan de requête qui impliquent l'utilisation d'opérations de base de données tempdb . Par conséquent, les gains de performance varient considérablement en fonction des charges de travail et de la conception de l'application. Nous vous recommandons de procéder à la meilleure solution pour déterminer les gains possibles et évaluer les besoins de sécurité d'e/s avant un tel déploiement de test.

SQL Server utilise la base de données tempdb pour gérer les diverses activités impliquant trie, hachages, la banque de versions de ligne et tables de température :
  • Les tables temporaires sont conservées par les routines de pool de mémoire tampon commune pour les pages de données et généralement ne présentent pas des avantages de performance à partir des implémentations de sous-système de spécialisation.
  • La base de données tempdb est utilisée comme un plan de montage pour les hachages et les tris. Réduction de la latence d'e/s pour des opérations peut être bénéfique. Cependant, savoir que l'ajout d'un index pour éviter un hachage ou un tri peut fournir le même avantage.
Exécuter des lignes de base avec et sans la base de données tempdb sur le sous-système haute vitesse pour comparer les avantages. Partie des essais doit inclure des requêtes sur la base de données utilisateur qui ne pas impliquer des tris, des hachages ou des tables temporaires et puis confirmer que ces requêtes ne sont pas affectés négativement. Lorsque vous évaluez le système, les indicateurs de performance suivants peuvent être utiles.
IndicateurDescription de l'utilisation
Page lectures et écrituresAmélioration des performances de tempdb la base de données e/s peut modifier le taux de lectures de pages et écrit pour les bases de données utilisateur en raison de la latence réduite associée à la base de données tempdb d'e/s. Pour les pages de base de données d'utilisateur, le nombre global ne doit pas varier au sein de la même charge de travail.
Physique lire et écrire des octets dans la base de données tempdbSi le déplacement de la base de données tempdb sur un périphérique, tel qu'un disque RAM, augmente l'e/s réelles de la base de données tempdb , il indique que la mémoire du pool de tampons est à l'origine une activité de base de données accrue tempdb à se produire. Ce modèle est un indicateur que l'espérance de vie de page de base de données des pages mai également être affectées de manière négative.
Espérance de vie de pageUne baisse de l'espérance de vie de page peut indiquer une augmentation des exigences d'e/s physiques pour une base de données utilisateur. La diminution du taux indique probablement que la mémoire du pool de tampons oblige les pages de base de données pour quitter le pool de tampons prématurément. Combiner avec les autres indicateurs et de test afin de comprendre parfaitement les limites du paramètre.
Débit global
Utilisation de l'UC
Évolutivité
Temps de réponse
Le principal objectif d'un changement de configuration de base de données tempdb est d'augmenter le débit global. Votre test doit inclure une combinaison des charges de travail reproductibles qui peut être distribuée horizontalement afin de déterminer la façon dont le débit est affecté.

Par exemple, une implémentation basée sur la compression de disque RAM peut fonctionner avec 10 utilisateurs. Toutefois, la charge de travail accrue, peut pousser des niveaux du processeur au-delà des niveaux souhaités et avoir des effets négatifs sur le temps de réponse lorsque les charges de travail sont élevés. Les tests de stress trues future prediction et tests de charge sont vivement encouragés.
Fichiers de travail et les actions de création de table de travailSi la base de données tempdb sur un périphérique, tel qu'un disque RAM, changement du plan de requête en augmentant le nombre ou la taille des fichiers de travail ou des tables de travail, il indique que la mémoire du pool de tampons est à l'origine une activité de base de données accrue tempdb à se produire. Ce modèle est une indication que l'espérance de vie de page des pages de base de données peuvent également être affectée de manière négative.

Exemple de réécriture secteur transactionnelle

L'exemple suivant décrit plus en détail la sécurité des données requis par les bases de données SQL Server.

Supposons qu'un fournisseur de disque RAM utilise une implémentation de la compression en mémoire. La mise en oeuvre doit être encapsulé correctement en fournissant l'apparence physique du flux de fichier comme si le secteur a été aligné et donc SQL Server est correctement sécurisé à partir de l'implémentation sous-jacente et ignore de taille. Regardez de plus près l'exemple de compression.
Action
Secteur 1 est écrit sur le périphérique et est compressée pour économiser de l'espace.
Secteur 2 est écrit sur le périphérique et est compressé avec secteur 1 pour économiser de l'espace.
Le périphérique peut effectuer les actions suivantes pour vous aider à sécuriser les données de secteur de 1 lorsqu'il est combiné avec des données de secteur 2.
Action
Bloquer toutes les écritures dans les secteurs 1 et 2.
Décompresser le secteur 1 dans une zone de travail, en laissant de stockage secteur 1 actuel en tant que les données actives à récupérer.
Compresser en un nouveau format de stockage des secteurs 1 et 2.
Bloquer toutes les lectures et écritures des secteurs 1 et 2.
Ancien stockage pour des secteurs de 1 et 2 avec un nouveau stockage pour Exchange.
Si la tentative d'exchange échoue (rollback) :
  • Restaurer le stockage d'origine pour les secteurs 1 et 2.
  • Supprimer les données de secteurs 1 et 2 combinés dans le plan de montage.
  • Échec de l'opération d'écriture de secteur 2.
Débloquer les lectures et écritures des secteurs 1 et 2.
La possibilité de fournir des mécanismes de verrouillage autour de la modification du secteur et annuler les modifications en cas d'échec de la tentative d'exchange de secteur est considéré comme conforme à laquellle. Pour les implémentations qui utilisent le stockage physique pour le stockage étendu, il est supposé contenir les aspects du journal de transaction approprié pour protéger et restaurer les modifications qui ont été appliquées aux structures sur disque pour maintenir l'intégrité des fichiers de base de données SQL Server.

N'importe quel périphérique qui permet à la réécriture des secteurs doit prendre en charge les réécritures de façon transactionnelle afin que SQL Server n'est pas exposée à une perte de données.

Remarque L'instance de SQL Server est redémarré lorsque les e/s en ligne et les échecs de restauration se produisent dans la base de données tempdb .

Soyez prudent lorsque vous déplacez la base de données tempdb

Soyez prudent lorsque vous déplacez la base de données tempdb , car si la base de données tempdb ne peut pas être créé, SQL Server ne démarre pas. Si la base de données tempdb ne peut pas être créé, démarrez SQL Server en utilisant le (-f) paramètre de démarrage et de déplacer la base de données tempdb à un emplacement valide.

Pour modifier l'emplacement physique de la base de données tempdb , procédez comme suit :
  1. Utilisez l'instruction ALTER DATABASE et la clause MODIFY FILE pour modifier le nom de fichier physique de chaque fichier dans la base de données tempdb pour faire référence au nouvel emplacement physique, tel que le nouveau disque.
    Alter database tempdb modify file (name = tempdev, filename = 'C:\MyPath\tempdb.mdf')Alter database tempdb modify file (name = templog, filename = 'C:\MyPath\templog.ldf')
  2. Arrêtez, puis redémarrez SQL Server.

Certifications de produits partenaires ne sont pas un garantir de compatibilité ou de sécurité

Un produit tiers ou un fournisseur particulier peut recevoir un logo de certification Microsoft. Toutefois, certification partenaire ou un logo de Microsoft spécifique ne certifie pas la compatibilité ou l'adéquation à un usage particulier dans SQL Server.

Prise en charge

Si vous utilisez un sous-système avec SQL Server qui prend en charge les garanties d'e/s pour une utilisation de base de données transactionnelle comme décrit dans cet article, Microsoft fournira la prise en charge de SQL Server et les applications basées sur SQL Server. Toutefois, des problèmes, ou dû, le sous-système sera fait référence au fabricant.

Pour les problèmes liés à la base de données tempdb , les Services de support technique de Microsoft vous demandera de déplacer la base de données tempdb . Contactez votre fournisseur de périphérique pour vérifier que vous avez correctement déployé et configuré le périphérique pour une utilisation de base de données transactionnelle.

Microsoft ne certifie ni valider que des produits tiers fonctionnent correctement avec SQL Server. En outre, Microsoft ne fournit pas toute garantie ou déclaration d'adéquation de tout produit tiers pour une utilisation avec SQL Server.
Références
Pour plus d'informations, cliquez sur les numéros ci-dessous pour afficher les articles correspondants dans la Base de connaissances Microsoft :
826433 PRB : Les tests de diagnostic supplémentaires de SQL Server pour détecter les problèmes d'e/s non signalés
828339 Message d'erreur 823 peut indiquer des problèmes de matériel ou système dans SQL Server
234656 À l'aide de la mise en cache du lecteur de disque avec SQL Server
304261 Description de la prise en charge pour les fichiers de base de données réseau dans SQL Server
913945 Microsoft ne certifie pas que des produits tiers fonctionneront avec Microsoft SQL Server
910716 Configuration requise pour SQL Server 2005 et SQL Server 2000 pour prendre en charge la mise en miroir à distance de bases de données utilisateur
917043 Facteurs clés à prendre en compte lors de l'évaluation des systèmes de cache de fichiers tiers avec SQL Server
À l'aide de SSDs dans Azure VM pour stocker TempDB de SQL Server et des Extensions de Pool de mémoire tampon

Méthodes conseillées en matière de performances pour SQL Server sur des Machines virtuelles Azure

Optimisation de votre requête Plans avec le SQL Server estimation de cardinalité 2014

Performances des requêtes


Les informations contenues dans ce document représentent l'opinion actuelle de Microsoft Corporation sur les points cités à la date de publication. Étant donné que Microsoft doit s'adapter aux conditions changeantes du marché, il ne doit pas être interprétée comme un engagement de la part de Microsoft, et Microsoft ne peut garantir l'exactitude des informations présentées après la date de publication.

Ce livre blanc est publié à des fins d'information. MICROSOFT N'OFFRE AUCUNE GARANTIE, EXPRESSE, IMPLICITE OU LÉGALE CONCERNANT LES INFORMATIONS CONTENUES DANS CE DOCUMENT.

Respecter toutes les lois sur le copyright applicables est la responsabilité de l'utilisateur. Aucune partie de ce document peut être reproduite ou transmise sous quelque forme ou par quelque moyen que ce soit (électronique, mécanique, photocopie, enregistrement ou autre) ou à toute fin, sans la permission expresse et écrite de Microsoft Corporation.

Microsoft peut avoir des brevets, brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle couvrant un sujet dans ce document. Sauf disposition expressément stipulée dans un contrat de licence écrit de Microsoft, la fourniture de ce document non permet de vous concéder une licence sur ces brevets, marques, droits d'auteur ou autres droits de propriété intellectuelle.

© 2006 Microsoft Corporation. Tous droits réservés.

Microsoft, Windows, Windows Server et SQL Server sont soit des marques déposées ou des marques déposées de Microsoft Corporation aux États-Unis et/ou dans d'autres pays.
SQL Server nécessite des systèmes pour prendre en charge des « remise garantie sur un support stable » en tant qu'envertu avec contour Conditions du programme fiabilité d'e/s de SQL Server.Pour plus d'informations sur la configuration d'entrée et de sortie pour le moteur de base de données SQL Server, cliquez sur le numéro ci-dessous pour afficher l'article correspondant dans la Base de connaissances Microsoft :
967576 Configuration requise de Microsoft SQL Server de base de données moteur d'entrée/sortie


Avertissement : Cet article a été traduit automatiquement.

Atribuudid

Artikli ID: 917047 – viimati läbi vaadatud: 05/12/2015 21:04:00 – redaktsioon: 2.0

Microsoft SQL Server 7.0 Standard, Microsoft SQL Server 2000 Édition Personelle, Microsoft SQL Server 2000 Standard, Microsoft SQL Server 2000 Workgroup Edition, Microsoft SQL Server 2000 Édition Développeur, Microsoft SQL Server 2000 Édition Entreprise, Microsoft SQL Server 2005 Express Edition, Microsoft SQL Server 2005 Standard Edition, Microsoft SQL Server 2005 Workgroup Edition, Microsoft SQL Server 2005 Developer Edition, Microsoft SQL Server 2005 Enterprise Edition, Microsoft SQL Server 2008 Developer, Microsoft SQL Server 2008 Enterprise, Microsoft SQL Server 2008 Express, Microsoft SQL Server 2008 Standard, Microsoft SQL Server 2008 R2 Developer, Microsoft SQL Server 2008 R2 Enterprise, Microsoft SQL Server 2008 R2 Express, Microsoft SQL Server 2008 R2 Standard, Microsoft SQL Server 2012 Developer, Microsoft SQL Server 2012 Enterprise, Microsoft SQL Server 2012 Express, Microsoft SQL Server 2012 Standard, Microsoft SQL Server 2014 Business Intelligence, Microsoft SQL Server 2014 Developer, Microsoft SQL Server 2014 Enterprise, Microsoft SQL Server 2014 Enterprise Core, Microsoft SQL Server 2014 Express, Microsoft SQL Server 2014 Service Pack 1, Microsoft SQL Server 2014 Standard, Microsoft SQL Server 2014 Web

  • kbsql2005setup kbsql2005engine kbexpertiseadvanced kbinfo kbmt KB917047 KbMtfr
Tagasiside