Tableau verrouillé pendant les insertions ... site Web inutilisable (serveur SQL 2008)

Question

J'ai un processus d'arrière-plan qui est constamment inséré dans une table en temps réel. Il pourrait s'agir de milliers d'insertions par heure (avec quelques mises à jour). Cette même table est utilisée par l'application Web pour obtenir certaines données nécessaires à l'affichage pour l'utilisateur.

Actuellement, lorsque le processus d'arrière-plan exécute ses insertions/mises à jour, l'application Web semble bloquée et ne peut pas accéder à la base de données.

Je me demande quelle pourrait être une bonne solution. Dois-je créer une autre table dans laquelle insérer et copier la table vers une autre table en lecture seule? Y a-t-il une autre méthode?

Toute aide et suggestion est grandement appréciée!

Answer 1

Surtout pour SQL Server, vous voudrez peut-être changer votre base de données pour activer READ_COMMITTED_SHAPSHOT.

Cela empêche fondamentalement vos requêtes select de se bloquer si des insertions/mises à jour sont en attente sur les données.

Answer 2

Certaines choses à regarder serait:

1) Vos insérer/mises à jour ou vos requêtes de sélection le cadre d'opérations? Si oui, assurez-vous que vous avez défini le transaction isolation level le plus favorable pour votre situation particulière.

2) Avez-vous trop d'index sur cette table géante? Les index accélèrent la sélection mais ralentissent les insertions et les mises à jour. Assurez-vous de n'avoir que les index dont vous avez absolument besoin.

3) Relatif à # 2. Avez-vous des index qui vont accélérer vos sélections? Vos instructions select effectuent-elles des analyses de table complètes? Jetez un coup d'œil au plan d'exécution de la requête pour voir ce qui se passe réellement. (Analyseur de requêtes peut vous aider avec cela). 4) Envisagez de répliquer vos données géantes vers un ou plusieurs serveurs de base de données en lecture seule capables de gérer le trafic sélectionné alors que la table principale en lecture/écriture (c'est-à-dire votre table existante) traite principalement le trafic d'insertion/mise à jour.

5) Avez-vous des déclencheurs qui déclenchent vos opérations d'insertion/de mise à jour qui peuvent causer des problèmes de performance ou de verrouillage?

6) Votre application rencontre-t-elle des transactions bloquées? Jetez un oeil à ce MSDN article sur le sujet et voir si cela aide. En outre, assurez-vous de comprendre le dining philosophers problem pour éviter les transactions bloquées.

Answer 3

Si vous utilisez Enterprise Edition, la solution idéale serait d'utiliser le partitionnement de fenêtre coulissante. Essentiellement, vous créez une table identique sur le même groupe de fichiers, chargez les données dans ladite table, puis "basculez" la partition de la table dans votre table de production. L'opération proprement dite n'est qu'une bascule de métadonnées, ce qui se produit plus ou moins instantanément. Regardez ici pour plus d'informations: http://technet.microsoft.com/en-us/library/ms191160.aspx

Answer 4

Si vous avez juste besoin de lire les données de la table dans l'application Web, vous pouvez essayer d'utiliser le niveau d'isolation READ_UNCOMMITTED pour la requête. Il ne prend aucun verrou et lit les données non validées. Je ne recommanderais pas de faire cela pour quelque chose comme une application bancaire, mais la plupart des applications web d'affaires typiques n'auraient probablement pas de problème avec cela. Assurez-vous de redéfinir le niveau d'isolation sur ce que vous utilisez habituellement (READ COMMITTED?) Après la requête.

Si vous utilisez READ_UNCOMMITTED n'est pas bon pour vous, vous pouvez vous familiariser avec Row Versioning-Based isolation levels. Par exemple, l'isolation des instantanés utilise une approche optimiste de la modification des données, ce qui réduit le besoin d'effectuer un verrouillage pessimiste des lignes.