D'accord avec Marc et Unkown ci-dessus ... 6 index dans l'index clusterisé, c'est beaucoup trop, surtout sur une table qui n'a que 14 colonnes. Vous ne devriez pas en avoir plus de 3 ou 4, si cela, je dirais 1 ou peut-être 2. Vous savez peut-être que l'index clusterisé est la table réelle sur le disque, donc lorsqu'un enregistrement est inséré, le moteur de base de données doit le trier et placez-le dans son endroit organisé trié sur le disque. Les index non clusterisés ne le sont pas, ils prennent en charge les "tables" de recherche. Mes VLDB sont disposées sur le disque (CLUSTERED INDEX) selon le 1er point ci-dessous.
- Réduisez votre index clusterisé à 1 ou 2. Les meilleurs choix de champ sont IDENTITY (INT), si vous en avez un, ou un champ de date dans lequel les champs sont ajoutés à la base de données, ou un autre champ qui est un sorte naturelle de la façon dont vos données sont ajoutées à la base de données. Le fait est que vous essayez de conserver ces données au bas du tableau ... ou de les disposer sur le disque de la meilleure manière (90% +) pour lire les enregistrements. Cela fait en sorte qu'il n'y a pas de réorganisation en cours ou qu'il faut un et un seul coup pour obtenir les données au bon endroit pour une meilleure lecture. Veillez à placer les champs supprimés dans des index non clusterisés afin de ne pas perdre l'efficacité de la recherche. Je n'ai JAMAIS mis plus de 4 champs sur mes VLDB. Si vous avez des champs qui sont mis à jour fréquemment et qu'ils sont inclus dans votre index clusterisé, OUCH, cela va réorganiser l'enregistrement sur le disque et provoquer une fragmentation COÛTEUSE.
- Vérifiez le facteur de remplissage sur vos index. Plus le nombre de facteurs de remplissage est élevé (100), plus les pages de données et les pages d'index seront complètes. En fonction du nombre d'enregistrements que vous avez et du nombre d'enregistrements que vous insérez, vous modifierez le facteur de remplissage # (+ ou -) de vos index non clusterisés pour permettre l'espace de remplissage lorsqu'un enregistrement est inséré. Si vous modifiez votre index clusterisé en un champ de données séquentiel, cela n'aura pas autant d'importance sur un index clusterisé. Règle empirique (IMO), facteur de remplissage 60-70 pour les écritures élevées, 70-90 pour les écritures moyennes et 90-100 pour les lectures élevées/écritures faibles. En laissant tomber votre facteur de remplissage à 70, cela signifie que pour 100 enregistrements sur une page, 70 enregistrements sont écrits, ce qui laissera un espace libre de 30 enregistrements pour les enregistrements nouveaux ou réorganisés. Occupe plus d'espace, mais c'est mieux que d'avoir à défragmenter tous les soirs (voir 4 ci-dessous)
- Assurez-vous que les statistiques existent sur la table. Si vous souhaitez balayer la base de données pour créer des statistiques à l'aide de "sp_createstats 'indexonly'", alors SQL Server créera toutes les statistiques sur tous les index que le moteur a accumulés comme nécessitant des statistiques. Ne laissez pas l'attribut 'indexonly' ou vous ajouterez des statistiques pour chaque champ, ce ne serait alors pas bon.
- Vérifiez la table/les index à l'aide de DBCC SHOWCONTIG pour voir quels index sont le plus fragmentés. Je n'entrerai pas dans les détails ici, sachez simplement que vous devez le faire. Ensuite, en fonction de ces informations, augmentez ou diminuez le facteur de remplissage en fonction des modifications apportées aux index et de la vitesse (au fil du temps).
- Configurez une planification de tâche qui s'exécutera en ligne (DBCC INDEXDEFRAG) ou hors ligne (DBCC DBREINDEX) sur des index individuels pour les défragmenter. Attention:ne faites pas DBCC DBREINDEX sur cette grande table sans que ce soit pendant la période de maintenance car cela entraînera la panne des applications ... en particulier sur le CLUSTERED INDEX. Tu as été prévenu. Testez et testez cette partie.
- Utilisez les plans d'exécution pour voir quels SCANS et FAT PIPES existent et ajustez les index, puis défragmentez et réécrivez les procs stockés pour vous débarrasser de ces points chauds. Si vous voyez un objet RED dans votre plan d'exécution, c'est qu'il n'y a pas de statistiques sur ce champ. C'est mauvais. Cette étape relève plus de "l'art que de la science".
- En dehors des heures de pointe, exécutez UPDATE STATISTICS WITH FULLSCAN pour donner au moteur de requête autant d'informations que possible sur les distributions de données. Sinon, effectuez les STATISTIQUES DE MISE À JOUR standard (avec un balayage standard de 10 %) sur les tables pendant les nuits de semaine ou plus souvent selon vos observations pour vous assurer que le moteur dispose de plus d'informations sur les distributions de données pour récupérer les données efficacement.
Désolé c'est si long, mais c'est extrêmement important. Je ne vous ai donné ici qu'un minimum d'informations, mais cela vous aidera énormément. Il y a des intuitions et des observations qui entrent dans les stratégies utilisées par ces points qui nécessiteront votre temps et vos tests.
Pas besoin de passer à l'édition Enterprise. Je l'ai fait pour obtenir les fonctionnalités évoquées précédemment avec le partitionnement. Mais j'ai SURTOUT fait pour avoir de bien meilleures capacités multi-threading avec la recherche et le DEFRAGING et la maintenance en ligne... En édition Enterprise, c'est bien mieux et plus convivial avec les VLDBs. L'édition standard ne gère pas non plus DBCC INDEXDEFRAG avec les bases de données en ligne.
