SSRS verrouille-t-il la table lors de la requête?

9

Mon DBA principal m'a dit que l'exécution de SQL Query par défaut ne verrouille pas la table.

J'avais des problèmes avec mon rapport SQL Server Reporting Services (SSRS) qui semble avoir des problèmes de verrouillage et des erreurs.

J'ai fait des recherches sur Google, mais je n'ai rien trouvé.

Les rapports SSRS verrouillent-ils les tables interrogées?

Existe-t-il une documentation MSDN qui documente spécifiquement ce comportement?

sql-server-2008 locking

— melaos
source

Nous avons eu le même problème. Bien que ce ne soit techniquement pas une réponse à vos questions, nous avons fait une solution rapide en démarrant des requêtes de jeux de données avec SET TRANSACTION ISOLATION LEVELpar exemple READ UNCOMMITTEDsi cela ne vous dérange pas de risquer quelques lectures sales.

— Jeroen

Tout comme une note pour l'avenir, vous pouvez rediriger la charge de génération de rapports vers des secondaires lisibles avec un groupe de disponibilité AlwaysOn dans SQL 2012. msdn.microsoft.com/en-us/library/hh882437.aspx

— wBob

7

Réponse courte: Non

Plus long...

SQL Server ne sait pas que SSRS lui envoie une requête. Ainsi, la requête de SSRS s'exécutera comme n'importe quelle autre requête.

Il est plus probable que l'optimiseur de requêtes décide d'utiliser un verrou de table pour la requête SSRS. bien sûr, cela pourrait être un problème différent, mais c'est une question différente

— gbn
source

mm alors SRSS essaie-t-il de verrouiller la table quand il interroge alors?

— melaos

L'instruction T-SQL entraîne un certain type de verrou ou un autre, selon l'instruction T-SQL. Cela ne dépend pas de l'origine de cette instruction (SSRS, fenêtre de requête, application, etc.)

— Eric Higgins

4

mon aîné m'a dit que pour l'exécution de requêtes SQL par défaut ne verrouille pas la table.

C'est vrai. Cependant, cela ne signifie pas qu'une requête ne peut pas verrouiller une table.

le rapport SSRS verrouillera-t-il réellement les tables interrogées?

SSRS obtient les données utilisées pour rendre le rapport en exécutant une requête ou une procédure stockée sur la base de données.

Cette requête est définie par le développeur, et elle peut finir par verrouiller une table (ou des tables), selon le niveau d'isolement et le nombre de lignes impliquées. (En fait, il peut y avoir des cas où vous voudriez le faire exprès .) L'essentiel est que c'est au développeur comment le verrouillage fonctionne pour la requête. SSRS ne peut pas résoudre ce problème pour vous. C'est pourquoi il n'y a pas de documentation.

Considérez (par exemple):

Utilisation READ UNCOMMITTEDsi les lectures sales sont correctes
Activation et utilisation d'un niveau d'isolement d'instantané
Envoi de journaux en mode veille et exécution de requêtes sur la copie en lecture seule

— Jon Seigel
source

2

Comment savez-vous qu'il existe un verrou lorsque le rapport est en cours d'exécution? Je vous suggère de vérifier la requête / le processus stocké qui est la source du rapport et de vous assurer qu'il fonctionne bien par lui-même.

Si vous êtes sûr que la requête source fonctionne correctement, essayez d'identifier le problème à l'aide du profileur SQL Server. Le lien ci-dessous pourrait vous aider:
/programming/9107383/sql-server-profiler-capture-calls-to-your-databases-stored-procs-during-ssrs

— Ciel
source

parce que j'exécutais le rapport sur quelques navigateurs et que le rapport continuait à recevoir des erreurs selon lesquelles le processus était verrouillé avec un verrou mort.

— melaos

Dans ce cas, votre rapport essaie probablement de lire des données verrouillées par un autre utilisateur (par exemple, quelqu'un met à jour le même enregistrement). Vous pouvez ajouter "sans verrou" à toutes les instructions "Select", si la lecture des données non validées est correcte.

— Sky