Dans MS SQL Server nolockpeut être utilisé à cet effet.
Pourquoi ne pouvons-nous pas l'utiliser dans Oracle et plsql?
14
Dans MS SQL Server nolockpeut être utilisé à cet effet.
Pourquoi ne pouvons-nous pas l'utiliser dans Oracle et plsql?
SQL Server utilise normalement une stratégie de verrouillage différente d'Oracle. La stratégie par défaut utilisée par SQL Server signifie que la sélection de lignes entraîne le placement de verrous de lecture (sur les lignes, les pages ou la table entière) *. Par conséquent, la NOLOCKclause est parfois utile - bien que le conseil général soit de ne jamais l'utiliser, car elle modifie la sémantique des niveaux d'isolement et peut entraîner des résultats incohérents dans la sortie des requêtes.
* (Remarque: c'est la valeur par défaut. Si l' SNAPSHOTisolement est choisi, le comportement est différent et les lecteurs ne bloquent pas les écrivains.)
Dans Oracle, un processus de lecture ne bloquera jamais un processus d'écriture. Ce qui suit est un extrait de ' Oracle Database Concepts 11g Release 2 '. Je vous encourage à jeter un œil si vous êtes intéressé par la façon dont cela est géré par Oracle.
Concurrence et cohérence des données
Résumé du comportement de verrouillage
La base de données gère plusieurs types de verrous différents, en fonction de l'opération qui a acquis le verrou. En général, la base de données utilise deux types de verrous: les verrous exclusifs et les verrous partagés. Un seul verrou exclusif peut être obtenu sur une ressource telle qu'une ligne ou une table, mais de nombreux verrous de partage peuvent être obtenus sur une seule ressource.
Les verrous affectent l'interaction des lecteurs et des écrivains. Un lecteur est une requête d'une ressource, tandis qu'un écrivain est une instruction modifiant une ressource. Les règles suivantes résument le comportement de verrouillage d'Oracle Database pour les lecteurs et les écrivains:
• Une ligne n'est verrouillée que lorsqu'elle est modifiée par un écrivain.
Lorsqu'une instruction met à jour une ligne, la transaction acquiert un verrou pour cette ligne uniquement. En verrouillant les données de table au niveau de la ligne, la base de données minimise les conflits pour les mêmes données. Dans des circonstances normales 1, la base de données n'escalade pas un verrou de ligne au niveau du bloc ou de la table.
• Un écrivain d'une ligne bloque un écrivain simultané de la même ligne.
Si une transaction modifie une ligne, un verrou de ligne empêche une transaction différente de modifier la même ligne simultanément.
• Un lecteur ne bloque jamais un écrivain.
Parce qu'un lecteur d'une ligne ne la verrouille pas, un écrivain peut modifier cette ligne. La seule exception est une instruction SELECT ... FOR UPDATE, qui est un type spécial d'instruction SELECT qui verrouille la ligne qu'elle lit.
• Un écrivain ne bloque jamais un lecteur.
Lorsqu'une ligne est modifiée par un rédacteur, la base de données utilise des données d'annulation pour fournir aux lecteurs une vue cohérente de la ligne.