Quels risques existe-t-il si nous activons un instantané lu avec validation dans SQL Server?

J'ai lu ici que des données supplémentaires seront stockées par ligne, ce qui pourrait entraîner une dégradation des performances, mais quels sont les autres risques?

par exemple. Cela affectera-t-il la récupération de la base de données? Y a-t-il autre chose que nous devons faire pour profiter de cela?

Je prévois d'exécuter ces commandes:

ALTER DATABASE DatabaseName SET READ_COMMITTED_SNAPSHOT ON
ALTER DATABASE DatabaseName SET ALLOW_SNAPSHOT_ISOLATION ON

Je pense que cela nous rapprochera de Oracle, où si une transaction est mise à jour, d'autres transactions peuvent toujours lire les anciennes données. Est-ce correct?

J'examine cela car je suis fatigué des problèmes de verrouillage dans SQL Server 2005. J'espère que cela pourrait réduire les blocages occasionnels que nos utilisateurs voient, améliorer les performances globales de notre application et encourager nos développeurs à effectuer plus d'une opération par transaction sans transaction. peur.

Sommaire

1. Si vous avez des problèmes de verrouillage, vous avez un problème avec votre code: ce n'est pas le moteur de base de données
2. Ce n'est pas une balle magique
3. Vous pouvez ajouter plus de problèmes

Charge

Cela augmentera également la charge sur votre tempdb et votre CPU . Regarde aussi:

• "Impact sur les performances: le coût potentiel de Read_Committed_Snapshot" (Linchi Shea)

sécurité

Plus important encore, les isolations d'instantanés ne sont pas sécurisées dans de nombreux cas par défaut . Lisez «Isolement instantané» (Wikipedia) pour en savoir plus sur les anomalies d'écriture oblique. La section suivante explique comment rendre l'isolation d'instantané sérialisable.

En général, l’isolation d’instantané pose donc une partie du problème du maintien de contraintes non triviales à l’utilisateur, qui peut ne pas apprécier les pièges potentiels ni les solutions possibles. L'avantage de ce transfert est une meilleure performance.

Regarde aussi:

• "Les dangers potentiels du niveau d'isolement de l'instantané lu commis" (Jim Mc Leod, contesté dans les commentaires de Alex Kuznetsov)
• Impasse!: "Lecture instantanée capturée" a expliqué (Nick Berardi)
• Serializable vs. Snapshot Isolation Level, le problème de marbre (Craig Freedman)
• Les lectures impliquant des fonctions définies par l'utilisateur sous READ_COMMITTED_SNAPSHOT peuvent sembler incohérentes (Alex Kuznetsov)

Je sais que c'est un vieux fil, mais je dirais que dans une large mesure, l'isolement instantané est une solution miracle. Cela éliminera tout votre blocage entre lecteurs et écrivains. Cela n'empêchera cependant pas les écrivains de bloquer d'autres écrivains. Il n'y a pas de chemin aux alentours.

D'après mon expérience, la charge supplémentaire sur la base de données TEMPDB est négligeable et les avantages du contrôle de version par ligne pour réduire le nombre de lecteurs bloqués sont énormes.

Pour référence, le versioning de ligne (isolement de capture instantanée) est la méthode Oracle a utilisé pendant des décennies pour obtenir l' isolement sans bloquer les lecteurs et l'Oracle DB j'ai travaillé pendant près de 20 ans d' expérience beaucoup moins de problèmes de blocage que SQL Server ne. La plupart des développeurs SQL hésitent à utiliser l'isolation de capture instantanée, car ils ont uniquement testé leur code sur des bases de données utilisant le paramètre par défaut.

Quelques points supplémentaires à ajouter aux autres réponses:

SET ALLOW_SNAPSHOT_ISOLATION ONactive uniquement l'isolation de capture instantanée dans une base de données. Pour profiter vous devez recoder et SET TRANSACTION ISOLATION LEVEL SNAPSHOTpour les transactions que vous voulez qu'il appliquer. Le code appelant devra être modifié pour gérer les erreurs de conflit de mise à jour.

Après SET READ_COMMITTED_SNAPSHOT ON, les instructions à la lecture validée utilisent la version de ligne. Notez que ceci est la version ligne au niveau de l'instruction pour les lectures uniquement . Pour les mises à jour, la ligne "réelle" est récupérée et les verrous de mise à jour sont appliqués. Voir la section Résumé du comportement dans Comprendre les niveaux d'isolement basés sur le versionnage des lignes.

Dans les deux cas, sans test exhaustif, vous risquez d’introduire de nouveaux problèmes dans le système.

Je pense que cela nous rapprochera de Oracle, où si une transaction est mise à jour, d'autres transactions peuvent toujours lire les anciennes données. Est-ce correct?

Oui, c'est correct .

Cela vaut la peine de lire les liens dans la réponse de gbn et je pense que la même chose s’applique à la MVCC par défaut d’Oracle à SQL Server en mode d’isolation de capture instantanée. J'ajouterais que si vous comprenez les pièges potentiels, les avantages de l'OMI dépassent de loin les difficultés supplémentaires (du point de vue d'Oracle) - et bien sûr que certains problèmes bloquants disparaissent légitimement, tel est le but de MVCC (il existe également une classe de problèmes de verrouillage qui ne vont pas disparaître en raison de problèmes de code, mais je suppose que vous comprenez cela).

Nous utilisons SNAPSHOT ISOLATION dans tous nos projets utilisant SQL Server DB. Pas plus d'erreurs SQL 1205, qui ne sont pas causées par un code d'application incorrect, mais par un comportement de verrouillage de page et de ligne par défaut.

L'impact sur les performances est minime et jusqu'à présent 7 ans se sont écoulés, des centaines de millions d'opérations ont été traitées dans différents systèmes, sans aucun problème en ce qui concerne SNAPSHOT ISOLATION.

Les situations dans lesquelles plusieurs threads mettent à jour des informations critiques pour l'entreprise sur une seule ligne en parallèle sont extrêmement exceptionnelles et les chances que SNAPSOLOT ISOLATION soit la cause de tout problème d'incohérence sont très proches de zéro.

Si vous avez un système OLTP qui, par sa conception, met à jour une seule ligne en fonction des données de ligne actuelles dans de nombreux threads, il est évident que SNAPSHOTS n'est pas acceptable dans de tels cas.

nous l’avions active et une étrange instruction sql de sélection exécutant 4 a jamais bloqué la totalité de la base de données, peu importe le nombre de cœurs et tous. Désactiver RCSI a résolu le problème. Je l’allumerais une fois que vous feriez face à d’autres impasses, pas par défaut.