3

Je veux faire près de 1000 insertions dans un tableau par seconde. Et aussi chaque jour je veux interroger toutes les lignes insérées juste une fois à la fois. Et je veux améliorer l'efficacité par le multi-threading et la connection-pooling. Mais je veux savoir quel niveau de contrôle de concurrence est plus approprié pour moi. La liste des options pour SQL-Server est MSDN Site.Quel niveau de verrouillage SQL-Server convient à l'insertion?

Merci.

+0

Parlez-vous de verrouillage lorsque vous faites des insertions? Ou de verrouillage lors de la lecture une fois par jour? Ou essayez-vous de vous assurer que plusieurs threads n'insèrent pas les mêmes éléments? – slugster

+0

Quotidien est un normal. Je veux changer les verrous d'insertion. Mais il devrait être compatible avec le Daily. – Shayan

Répondre

2

Vous devriez être OK avec le niveau d'isolation par défaut pour les insertions. Avez-vous un index clusterisé? Si c'est le cas, assurez-vous qu'il ne se fragmente pas lorsque vous insérez de nouvelles lignes. Généralement guid serait un mauvais candidat pour l'index clusterisé. De plus, si vous avez une édition Entreprise et que vous êtes capable d'identifier des partitions dans votre table, vous pouvez partitionner la table en utilisant cette colonne (par exemple région ou ville) et stocker les partitions de la table sur différents groupes de fichiers. De cette façon, vous pouvez éviter les conflits d'E/S. Si vous sélectionnez toutes les données une fois par jour et que vous souhaitez maintenir la vitesse d'insertion pendant la sélection sans trop de verrouillage, vous pouvez envisager de créer un snapshot de base de données (encore Enterprise Edition) et en sélectionner. Si vous pouvez vivre avec des lectures sales, vous pouvez ajouter un indice (nolock) à votre sélection.

2

Vous risquez d'aboyer dans le mauvais arbre. Jetez un oeil en utilisant row-versioning transaction isolation au lieu de fournir des conseils de verrouillage pour les déclarations individuelles.

Beaucoup de gens à qui j'ai parlé ont eu de bons résultats grâce à l'utilisation de READ COMMITTED SNAPSHOT - qui peut être activé au niveau de la base de données et ne nécessite aucun changement de code.

Je peux dire que SNAPSHOT m'a bien servi dans le passé, mais il nécessite un changement de code.

Et un mot d'avertissement, assurez-vous que votre débit de tempdb est bon, car la version-version augmente considérablement la charge sur tempdb.

Questions connexes