Résumé
Utilisation d’un cache d’écriture (également appelée écriture sauvegarder la mise en cache) contrôleur de disque peut améliorer les performances de SQL Server. Contrôleurs de cache d’écriture et de sous-systèmes de disques sont sûrs pour SQL Server, s’ils sont spécifiquement conçus pour une utilisation dans un environnement de données critiques de la base de données transactionnelle gestion (SGBD). Ces caractéristiques de conception doivent conserver les données mises en cache en cas de défaillance du système. À l’aide d’une alimentation externe sans coupure (UPS) pour y parvenir est généralement pas suffisant, des modes de défaillance qui ne sont pas liés à l’alimentation peuvent se produire.
La mise en cache des contrôleurs et des sous-systèmes de disques peut être sûr pour une utilisation par SQL Server. La plupart des nouvelles plates-formes de serveur spécialisé qui intègrent ces sont sécurisés. Toutefois, vous devez vérifier avec votre fournisseur de matériel pour vous assurer que le sous-système de disque a été spécifiquement testé et agréé pour une utilisation dans un environnement de système (SGBDR) de gestion de bases de données relationnelles transactionnel critiques données.
Plus d'informations
Les instructions de modification des données SQL Server génèrent les écritures de pages logiques. Ce flux d’écritures peut être décrit comme un trafic allant de deux emplacements : le journal et la base de données elle-même. Pour des raisons de performances, SQL Server diffère des écritures sur la base de données via son propre système de tampon de cache. Écrit dans le journal est momentanément différée jusqu’au moment de la validation. Ils ne sont pas mis en cache de la même manière que les écritures de données. Parce que les écritures de journal pour une page donnée est toujours précédant les données de la page est écrit, le journal est parfois appelé un « type » de journal.
L’intégrité transactionnelle est un des concepts fondamentaux d’un système de base de données relationnelle. Les transactions sont considérées comme unités de travail qui sont totalement lettrée ou totalement annulées atomiques. Le journal des transactions à écriture anticipée de SQL Server est un composant essentiel dans la mise en œuvre de l’intégrité transactionnelle.
N’importe quel système de base de données relationnelle doit également gérer un concept étroitement lié à l’intégrité transactionnelle, ce qui est reprise après une panne de système non planifié. Une variété de non idéal, les effets réels peuvent provoquer cette défaillance. Sur de nombreux systèmes de gestion de base de données, panne du système peut entraîner un processus de restauration manuelle dirigées par l’homme.
En revanche, le mécanisme de récupération de SQL Server est entièrement automatique et fonctionne sans intervention humaine. Par exemple, SQL Server peut être prise en charge d’une application de production critiques pour l’entreprise et une panne système à cause d’une fluctuation temporaire. Lors de la restauration de l’alimentation, le matériel du serveur doit redémarrer, logiciel réseau doit charger et initialiser et redémarrez SQL Server. Lorsque SQL Server s’initialise, il s’exécutera automatiquement son processus de récupération en fonction des données du journal de transactions. Ce processus se produit sans intervention humaine. Chaque fois que les stations de travail est redémarré, les utilisateurs se trouverait toutes leurs données présentes, jusqu'à la dernière transaction à que leur entrées.
L’intégrité transactionnelle de SQL Server et de la récupération automatique constituent une fonctionnalité d’enregistrement de temps-et-main de œuvre très puissante. Si un contrôleur de mise en cache d’écriture n’est pas correctement conçu pour une utilisation dans un environnement SGBD données critique transactionnelle, il peut compromettre la capacité de SQL Server à restaurer, par conséquent endommage la base de données. Cela peut se produire si le contrôleur intercepte les écritures de journal de transactions SQL Server et les tampons de cache dans un matériel sur la carte de contrôleur, mais ne conserve pas ces écrit pages lors d’une défaillance du système.
Contrôleurs de cache plus effectuent la mise en cache d’écriture. La fonction de mise en cache d’écriture ne peut pas toujours être désactivée.
Même si le serveur utilise un onduleur, cela ne garantit pas la sécurité des écritures en mémoire cache. De nombreux types de défaillances du système peuvent se produire qu’un onduleur ne résout pas. Par exemple, une erreur de parité de mémoire, une interruption du système d’exploitation ou un problème matériel provoquant une réinitialisation du système peut produire d’une interruption du système contrôlé. Une erreur de mémoire dans le cache d’écriture de matériel peut également entraîner la perte des informations vitales.
Un autre problème lié à un contrôleur de cache en écriture peut se produire lors de l’arrêt du système. Il n’est pas rare de « cycle » du système d’exploitation ou de redémarrer le système au cours des modifications de configuration. Même si un opérateur prudent suit la recommandation de système d’exploitation à attendre jusqu'à ce que toutes les activités de disque a cessé avant le redémarrage du système, mise en cache des écritures peuvent rester présents sur le contrôleur. Lorsque l’utilisateur appuie sur la combinaison de touches CTRL + ALT + SUPPR ou le bouton de réinitialisation est enfoncé, mise en cache des écritures peuvent être éliminés, potentiellement endommager la base de données.
Il est possible de concevoir un cache d’écriture de matériel qui prend en compte toutes les causes possibles de supprimer les données de cache Sales, qui seraient donc sûrs pour une utilisation par un serveur de base de données. Certaines de ces fonctionnalités inclut interceptant le bus RST signal afin d’éviter la réinitialisation non contrôlée du contrôleur de mise en cache, batterie de secours et mis en miroir ou de mémoire ERC (vérification des erreurs et correction). Vérifiez auprès de votre fournisseur de matériel pour vous assurer que le cache d’écriture inclut d’autres fonctionnalités nécessaires pour éviter la perte de données.
SQL Server nécessite des systèmes pour prendre en charge la « remise garantie sur un support stable » comme indiqué dans le programme d’évaluation de la Solution Microsoft SQL Server sacoche stockage. FoPour 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 :
Configuration requise de base de données moteur d’entrée/sortie 967576 de Microsoft SQL Server
