Comment utilisez-vous NOLOCK avec TADOQuery et TADOTable?

J'ai le texte SQL "SELECT * FROM TABLE1 WITH (NOLOCK)".Comment utilisez-vous NOLOCK avec TADOQuery et TADOTable?

Deux questions:

Comment puis-je faire mon TADOQuery utiliser l'indicateur NOLOCK sans avoir à inclure dans le texte SQL? J'ai littéralement des milliers de TADOQuery avec leur SQL construit dynamiquement, et il serait difficile d'ajouter WITH (NOLOCK) à chacun d'entre eux, pour ne pas mentionner que je l'utilise avec des plates-formes de base de données autres que MSSQL. Y a-t-il une propriété TADOQuery?
Comment obtenir la même chose avec un TADOTable? TADOTable n'a pas de SQL, alors comment lui dire d'utiliser l'indice NOLOCK?

Merci

Source

2010-10-01 C. Smith

si vous utilisez MS SQL, exécutez ci-dessous déclaration une fois sur la connexion

SET TRANSACTION NIVEAU ISOLEMENT LIRE UNCOMMITTED

Cheer AP

Source

2010-10-01 23:32:05 APZ28

Oui. Et connaissez-vous les implications? Si ce n'est pas le niveau par défaut, il y a une bonne raison. Les transactions et les verrous sont là pour protéger votre intégrité des données. Avant de jeter ça, j'y penserais à deux fois - il devrait y avoir une très bonne raison. –

Cette déclaration s'applique-t-elle uniquement à cette session (c'est-à-dire que je dois le faire chaque fois que je lance mon application)? Ou est-il défini sur la base de données elle-même en permanence? Cela affecte-t-il uniquement les instructions SELECT ou toutes les instructions SQL? –

C'est pour la session seulement. Cela affectera toutes les instructions DML, par exemple toute clause where "lira" la base de données. Votre requête peut (et va ...) renvoie des résultats qui n'ont jamais existé dans la base de données. Sauf si votre base de données est en lecture seule, vous cherchez des problèmes. En utilisant un indice NOLOCK pour une requête donnée, sachant quoi faire est ok. L'utiliser pour une session entière à moins que la base de données ne soit en lecture seule est très dangereux. La performance n'est pas tout. L'utilisateur préfère généralement le résultat correct, même s'il est plus lent, que le mauvais résultat plus rapidement. –

Conseils sont base de données spécifique, ce qui vous devez donner une bonne base de données pour chaque prise en charge. Dans certaines bases de données, il n'y a rien d'équivalent, par exemple, Oracle ne permet rien de semblable (les lecteurs ne bloquent jamais les écrivains et les écrivains ne bloquent jamais les lecteurs, donc pas besoin). À mon humble avis, vous ne devriez pas utiliser les composants TADOTable - de toute façon AFAIK vous n'avez aucun moyen de spécifier un indice pour la requête générée - qui est de toute façon trop générique.

Aussi, vous devriez être TRÈS attention d'utiliser NOLOCK. Cela signifie READ UNCOMMITTED, aka sale lit. Vous contournez la protection des transactions et, à moins d'avoir une très bonne raison de contourner ce problème, vous ne devriez pas - le gain en performance peut ne pas valoir la perte d'intégrité et de cohérence des données.

Source

2010-10-01 15:44:58

Informations complémentaires pour C. Smith: NOLOCK est une allusion à SQL optimiseur. S'il n'y a pas de SQL, il n'y a pas d'optimiseur SQL (vous n'y avez pas accès, de toute façon), ce qui signifie que vous ne pouvez pas donner l'indice. –

Même dans les environnements transactionnels, le gain peut être très élevé avec SQL Server (dans mon cas 2000, plus tard 2005), car il promeut trop rapidement les verrous de ligne aux verrous de table en charge. Ajout de nolock à toutes les tables qui sont juste lookup (et seulement changer une fois par an quand la machine est en cours de maintenance) amélioration des performances (mesurée sous tension live, pas synthétique) des requêtes avec beaucoup (5-6) table rejoint parfois plus de 100%. –

Oui, c'est la même raison pour laquelle les tables MySQL ISAM sont plus rapides que InnoDB: elles n'utilisent pas de transactions. Le problème est de savoir comment le mécanisme de verrouillage est conçu dans certaines bases de données - d'autres n'atteignent jamais le verrou. Je n'ai pas dit "n'utilise jamais NOLOCK". Je viens de dire * soyez très prudent *, parce que le PO a dit qu'il a * mille * de requêtes à changer, comme n'importe quel indice, vous devriez l'utiliser de la bonne façon dans la bonne situation seulement - sachant quels effets il a. –

Comment utilisez-vous NOLOCK avec TADOQuery et TADOTable?

Répondre

Questions connexes