SQL Q & A: Des données qui restent gérables

  • Article

Ce mois-ci, notre chroniqueur SQL Server permet aux lecteurs d'analyser des données différentes, de développer des stratégies et de gérer des données avec des groupes de fichiers.

Paul S. Randal

Chiffres ne mentent pas

Q. Je suis en train de mesurer la latence de la I/O de certains de nos bases de données et j'obtiens des résultats différents des vues de gestion dynamique (DMV) et les compteurs de l'analyseur de performances. Pouvez-vous expliquer pourquoi ces chiffres ne sont pas les mêmes ?

R : Ces deux méthodes utilisent le sys.dm_io_virtual_file_stats DMV (voir mon blog post pour plus d'informations sur l'utilisation de qui) et le compteur long. Disque s/lecture et Moy. Compteurs de disque s/écriture dans l'objet de disque physique dans l'analyseur de performances. Il est tout à fait possible que vous pourriez voir des résultats différents entre les deux mécanismes.

La DMV mesure la lecture cumulative et temps de décrochage d'écriture ou latence. Il fait ceci pour chaque fichier dans chaque base de données depuis la base de données a été mise en ligne (généralement depuis le dernier redémarrage de l'instance de SQL Server ). Diviser ces totaux par le nombre de lectures et écritures afin d'obtenir la moyenne lire et écrire des temps de latence de I/O. Ces moyennes sont pour toute la période de temps lorsque vous tout d'abord interrogez le DMV à quand cette base de données en question a été mise en ligne.

Les compteurs de l'analyseur de performances sont une moyenne mobile sur une période plus petite. Ces deux postes de grand blog, "Windows Performance Monitor Disk compteurs expliqué," et "de mesure latence de disque avec l'analyseur de performances (Perfmon) de Windows, « par le Windows Server Core team expliquer plus en détail. Vous obtenez ce qui équivaut à une vue instantanée du disque lu et latences d'écriture. Comme vous pouvez le voir, ces deux méthodes de mesure de la latence sont tout à fait différents, qui peut conduire à des résultats différents.

La DMV ne mesure que le temps de latence des fichiers de base de données de SQL Server . L'analyseur de performances consiste à mesurer toutes les e/s sur ce volume. Dans un environnement de stockage partagé, cela peut signifier beaucoup d'autres non -SQL Server de fichiers qui contribuent à l'e/s chargent sur le volume. Cela pourrait rendre la faible moyenne pour ce qui est l'analyseur de performances est en mesurant beaucoup d'e/s sur plusieurs fichiers. La moyenne de la DMV pourrait être plus élevée parce qu'il mesure moins d'e/s dans l'ensemble moins de fichiers.

Pour les mêmes raisons, il pourrait y avoir des performances médiocres depuis quelques temps sur le volume, mais pas SQL Server d'e/s dans le processus. Les compteurs de l'analyseur de performances refléterait la piètre performance. La DMV est mesurant seulement SQL Server e/s, les résultats DMV ne sont pas affectés par cette période de mauvais résultats.

Aussi n'oubliez pas que la DMV recueille des données agrégées. S'il y a une période de mauvais résultats avec seulement SQL Server e/s qui se produisent, les résultats DMV dépendront les e/s peu performants, même après que les performances s'améliorent à nouveau. Les compteurs de l'analyseur de performances tiendront compte des latences élevées pendant la période de mauvaises performances, puis faible latence lorsque les performances s'améliorent.

Comme vous pouvez le voir, pour avoir un sens des valeurs différentes, vous devez considérer qu'ils sont réellement mesure. Malheureusement, il n'y a aucun moyen de réinitialiser les compteurs DMV sans déconnecter momentanément la base de données souhaitée.

HA pour tout le monde

Q. J'ai été invité à travailler sur une nouvelle stratégie de haute disponibilité (HA) pour nos serveurs SQL. Je cherche des conseils de ce qu'il faut envisager et par où commencer. Pouvez-vous offrir des conseils ?

**R :**Un problème est de trouver technologie HA à utiliser lors de la conception de votre stratégie. Souvent, une entreprise ira avec la technologie titulaire juste parce qu'il est déjà en place. Pire encore, la société peut faire un choix arbitraire de la technologie en l'absence de critères clairs.

Pour concevoir la stratégie HA correcte, vous devez rassembler et analyser vos besoins. Sans cette étape cruciale, vous n'avez aucune chance de satisfaire les besoins d'affaires avec votre stratégie. Pour chaque portion de données auquel s'applique la stratégie HA, vous avez besoin de réponses aux questions suivantes :

  1. Quelle importance sont ces données par rapport à tout le reste ? Indiquant que tout est une priorité absolue et qu'il doit être protégé de tout aussi fonctionne avec une petite quantité de données, mais devient de plus en plus impraticable avec plusieurs téraoctets répartis sur plusieurs instances de SQL Server .
  2. La quantité de données l'entreprise peut se permettre de perdre ? Les propriétaires d'entreprise voudrais naturellement voir aucune perte de données.
  3. Combien de temps les données peuvent être indisponibles ? Les propriétaires d'entreprise aiment également aucune interruption de service. Bien que vous pouvez vous en approchez, il n'est malheureusement pas réalisable dans la réalité.
  4. Ne les articles no. 1 ou non. 2 changement à différents moments de la journée ou le week-end ? Cela peut avoir un effet profond sur votre capacité à répondre aux exigences. Aucune perte de données et les interruptions de service sont beaucoup plus réalisable pour une période limitée — dire, 09 à 17 en semaine, comparativement à 24 x 365.
  5. Est-il acceptable de compromettre les performances de la charge de travail afin de préserver la durabilité et la disponibilité des données ? Les seules technologies pouvant fournir aucune perte de données nécessitent la mise en miroir synchrone de I/O sous-système écrit (réplication SAN) ou les enregistrements de journal de transaction (base de données mise en miroir ou groupes de disponibilité de SQL Server 2012). Ces deux peuvent entraîner un retard de traitement, mais il est un compromis.
  6. Est la copie secondaire des données doit être lisible ou accessible en écriture ?

Une fois que vous êtes confronté à ces exigences, vous pouvez travailler à travers les limites imposées par l'entreprise et ensuite de compromis. Il est important de comprendre les limitations que vous travaillez au sein peuvent signifier que vous ne pouvez satisfaire toutes les exigences. Dans ce cas, vous et les gestionnaires d'entreprise devront accepter un compromis. Dans le cas contraire toute stratégie HA que vous concevez ne va pas répondre aux attentes. Il est encore plus probable, que votre solution se composera de plusieurs technologies, sachant les limites de chacun, ainsi que la façon dont ils travaillent ensemble, sera essentielles à votre succès.

Vous pourriez faire face à toute les limitations suivantes :

  • Budget
  • Puissance électrique disponible
  • Espace physique pour les nouveaux serveurs, de grilles et de conditionnement d'air
  • Personnel — personne n'est disponible pour gérer les nouveaux systèmes soit actuellement, personne n'a les compétences nécessaires pour mettre en œuvre et de gérer les nouvelles technologies nécessaires

Il y a des descriptions détaillées des technologies et des exemples stratégiques dans ces deux livres blancs :

Bien que ces livres blancs ont été écrits pour SQL Server 2008/2008 R2, tout en eux s'applique toujours. Découvrez également le livre blanc, "AlwaysOn Architecture Guide : Construction d'une haute disponibilité et reprise après sinistre en utilisant des groupes de disponibilité de AlwaysOn, "pour les dernières technologies de SQL Server 2012.

Le groupe vers le haut

Q. J'ai été informé par certains de mes collègues que je devrais utiliser les groupes de fichiers pour les nouvelles bases de données au lieu d'un seul fichier de données. Pouvez-vous expliquer certains des avantages et des inconvénients de le faire ?

**R :**Je ne peux pas penser des inconvénients de l'utilisation de groupes de fichiers, sauf peut-être aller trop loin et en utilisant des centaines d'entre eux. Pour autant que les avantages aller, plusieurs groupes de fichiers commencent à devenir nécessaire que vos bases de données de plus en plus (plus de 50 Go - 100 Go). Pourtant, il y a trois raisons principales pour les avoir.

Les groupes de fichiers permettent des restaurations rapides et ciblées lors d'une catastrophe. Imaginez que vous avez une base de données de 1 to, avec la plupart de l'espace occupé par une table de vente qui contient les données de 2009 à aujourd'hui. Si la base de données est détruit en cas de sinistre, ce qui est la plus petite quantité, que vous pouvez restaurer ? Si tout est dans un groupe de fichiers ne sont pas là toutes les options, vous devez restaurer l'ensemble 1To, y compris toutes les données plus anciennes.

Une meilleure approche pour la reprise après sinistre est si vous avez des groupes de fichiers distincts : primaire, 2009, 2010, 2011, 2012 et 2013. En cas de catastrophe, que les données de 2013 pour être en ligne aussi vite que possible. C'est ce qui prend en charge votre système de vente Online Transaction Processing (OLTP). Aussi longtemps que vous avez SQL Server Enterprise edition, vous pouvez tirer parti de disponibilité de base de données partielle et commencer ce processus en rétablissant le groupe de fichiers primaire à l'aide de la syntaxe avec partielle. Ensuite, vous pouvez restaurer les autres groupes de fichiers que vous souhaitez en ligne tout de suite. Ensuite, vous pouvez terminer la séquence de restauration.

Vous pouvez restaurer les autres groupes de fichiers en ligne et à votre guise. Maintenant vous êtes exploitant une autre fonctionnalité d'édition Enterprise appelée « restauration fragmentaire en ligne. » Il s'agit d'une combinaison de caractéristiques de bases de données très volumineuses (VLDB). Ces caractéristiques réduisent les temps d'arrêt et vous donnent une grande flexibilité lorsqu'il s'agit de donner la priorité de votre séquence de restauration en cas de catastrophe. Cela signifie aussi que vous pouvez effectuer une restauration fragmentaire, si seulement une partie de la base de données est endommagée pour une raison quelconque. Cela limite encore davantage les exigences en matière de temps d'arrêt en cas de catastrophe.

La deuxième raison pour utiliser les groupes de fichiers doit soutenir le partitionnement et meilleure facilité de gestion. Partitionnement vous permet de charger facilement et de suppression des données d'une grande table très rapidement, sans générer beaucoup de journal de transactions. Entièrement expliquant les avantages du partitionnement est abordée dans cette colonne, mais les livres blancs suivants font un excellent travail, à l'aide de différents exemples de scénarios :

Une autre caractéristique de la facilité de gestion traite de fragmentation. En utilisant le même exemple de table sales comme avant, si vous avez des index sur la table sales qui se fragmenter et de la table et les index ne sont pas partitionné, puis l'ALTER INDEX... RECONSTRUIRE ou réorganiser commandes devront fonctionner sur la totalité de l'index en cours de défragmentation. Cela est vrai même si des données anciennes ne sera pas être fragmentées. Si vous avez divisé le tableau en plusieurs partitions, chacune dans un groupe de fichiers séparé, vous pouvez défragmenter uniquement les partitions de l'index qui sont fragmentés. Cela permet d'économiser beaucoup de temps et de ressources.

Enfin, les groupes de fichiers vous permettent d'isoler les différentes charges de travail au sein de la base de données sur différentes portions du sous-système d'e/s. Par exemple, imaginez que vous avez quelques tables légèrement usagés et quelques-uns qui sont largement utilisés et mis à jour. Si tout est dans un groupe de fichiers, vous pouvez constater que la performance opérationnelle sur les tables légèrement usagés est compromise en raison d'opérations sur les tableaux lourdement mis à jour.

Dans ce cas, vous pourriez séparer les tableaux légèrement utilisés dans un groupe de fichiers sur sa propre part du sous-système d'e/s. Puis stocker chacune des tables largement utilisés et mis à jour dans les groupes de fichiers distincts. Ont chacune sur sa propre part du sous-système d'e/s. Ceci sépare la charge de I/O pour les charges de travail n'interfèrent pas entre eux.

Vous devrez également faire cela au sein d'une même table, s'il y a une charge de travail OLTP sur les données les plus récentes (par exemple, dans une table sales, comme discuté plus tôt) et une charge d'entrepôt de données sur des données anciennes. Il s'agit d'un cas de partitionnement sera nécessaire et différentes charges de travail seront confinés pour séparer les partitions de la table sur les groupes de fichiers distincts — séparer à nouveau les charges de travail les uns des autres.

Paul S. Randal

Paul S. Randal est le directeur général de SQLskills.com, directeur régional Microsoft et un SQL Server MVP. Il a travaillé sur l'équipe SQL Server du moteur de stockage chez Microsoft de 1999 à 2007. Il a écrit DBCC CHECKDB/réparation pour SQL Server 2005 et a été chargé par le moteur de stockage de base au cours du développement de SQL Server 2008. Randal est un expert en sinistre, de haute disponibilité et de maintenance de base de données et est présentatrice régulière à des conférences dans le monde entier. Il blogs à SQLskills.com/blogs/paul, et vous pouvez le retrouver sur Twitter à Twitter.com/PaulRandal.

Contenus associés