La requête rapide est lente dans SSRS
J'ai un rapport SSRS qui appelle une procédure stockée. Si j'exécute la procédure stockée directement à partir d'une fenêtre de requête, elle sera renvoyée dans moins de 2 secondes. Toutefois, la même requête exécutée à partir d'un rapport SSRS 2005 prend jusqu'à 5 minutes. Cela ne se produit pas seulement lors du premier passage, cela se produit à chaque fois. De plus, je ne vois pas le même problème dans d'autres environnements.
Des idées sur la raison pour laquelle le rapport SSRS serait si lent dans cet environnement particulier?
Merci pour les suggestions fournies ici. Nous avons trouvé une solution qui s'est avérée liée aux paramètres. SQL Server était en train de générer un plan d’exécution compliqué lorsqu’il était exécuté à partir du rapport SSRS en raison de la détection de paramètres. La solution de contournement consistait à déclarer des variables à l'intérieur de la procédure stockée et à affecter les paramètres entrants aux variables. Ensuite, la requête a utilisé les variables plutôt que les paramètres. Cela a entraîné l'exécution cohérente de la requête, qu'elle ait été appelée à partir de SQL Server Manager ou via le rapport SSRS.
Ajoutez ceci à la fin de votre proc: option(recompile)
Le rapport sera exécuté presque aussi vite que la procédure stockée.
J'ajouterai que j'avais le même problème avec une requête de procédure non stockée - juste une instruction select simple. Pour résoudre ce problème, j'ai déclaré une variable dans l'instruction SQL de l'ensemble de données et je l'ai définie sur le paramètre SSRS.
Quelle solution de contournement ennuyeuse! Néanmoins, merci à vous tous de m'avoir approché de la réponse!
J'ai eu le même problème, voici ma description du problème
"J'ai créé une procédure de stockage qui générerait 2 200 lignes et serait exécutée en presque 2 secondes. Toutefois, après avoir appelé la procédure de stockage à partir de SSRS 2008, le rapport n'a jamais été exécuté et je dois finalement tuer le BIDS (Studio de développement Business Intelligence) du gestionnaire de tâches ".
Ce que j’ai essayé: j’ai essayé d’exécuter le SP à partir de la connexion de reportuser mais SP fonctionnait normalement pour cet utilisateur également; j’ai vérifié Profiler mais rien n’a fonctionné.
Solution:
En réalité, le problème est que, même si SP génère le résultat, le moteur SSRS prend le temps de lire ces nombreuses lignes et de les restituer. J'ai donc ajouté l'option WITH RECOMPILE dans SP et j'ai exécuté le rapport .. c'est à ce moment que le miracle s'est produit et que mon problème a été résolu.
Si votre procédure stockée utilise serveurs liés ou openquery , ils peuvent s'exécuter rapidement par eux-mêmes mais le rendu dans SSRS prend beaucoup de temps. Quelques suggestions générales:
- Récupérez les données directement à partir du serveur où les données sont stockées en utilisant une source de données différente au lieu d'utiliser le serveur lié pour récupérer les données.
- Chargez les données du serveur distant dans une table locale avant d'exécuter le rapport, en gardant la requête simple.
- Utilisez une variable de table pour récupérer d’abord les données du serveur distant, puis rejoignez vos tables locales au lieu de renvoyer directement une jointure avec un serveur lié.
Je vois que la question a été répondue, je ne fais qu'ajouter ceci au cas où quelqu'un aurait le même problème.
J'ai simplement désélectionné 'Répéter les colonnes d'en-tête sur chaque page' dans les propriétés du tableau matriciel.
Le même scénario se produisait. Un rapport très basique, le SP (qui ne prend qu'un paramètre) prenait 5 secondes pour ramener des enregistrements de 10 000 $, mais le rapport ne prendrait que 6 minutes. Selon le profileur et la table RS ExecutionLogStorage, le rapport consacrait tout son temps à la requête. Le commentaire de Brian S. m'a conduit à la solution .. J'ai simplement ajouté WITH RECOMPILE avant l'instruction AS dans le SP, et maintenant l'heure du rapport correspond à peu près au temps d'exécution SP.
J'ai rencontré un problème similaire lié à l'exécution rapide de ma procédure stockée à partir de Management Studio, mais très lente à partir de SSRS. Après une longue lutte, j'ai résolu ce problème en supprimant physiquement la procédure stockée et en la recréant. Je ne suis pas sûr de la logique sous-jacente, mais je suppose que cela tient à la modification de la structure de la table utilisée dans la procédure stockée.
J'ai eu le problème de sortie de rapport HTML sur le rapport récupérant 32000 lignes. La requête a fonctionné rapidement, mais la sortie dans le navigateur Web a été très lente. Dans mon cas, je devais activer la «pagination interactive» pour permettre à l'utilisateur de voir la première page et de générer un fichier Excel. Le principal avantage de cette solution est que la première page apparaît rapidement et que l'utilisateur peut générer une exportation au format Excel ou PDF, mais qu'il ne peut faire défiler que la page actuelle. Si l'utilisateur veut voir plus de contenu, il doit utiliser les boutons de navigation au-dessus de la grille. Dans mon cas, l'utilisateur a accepté ce comportement car l'exportation vers Excel était plus importante.
Pour activer la «pagination interactive», vous devez cliquer sur la zone disponible dans le volet de rapport et modifier la propriété «InteractiveSize»\«Hauteur» au niveau du rapport dans le volet de propriétés. Définissez cette propriété sur une valeur différente de 0. J'ai défini la valeur 8,5 pouces dans mon cas. Assurez-vous également que vous avez décoché la propriété "Conserver ensemble sur une page si possible" au niveau du tableau matriciel (clic droit sur le tableau matriciel, puis "Propriétés du tableau matriciel", puis "Général"\"Options de saut de page").
J'ai fait face au même problème. Pour moi, c'était juste pour décocher l'option:
Propriétés du tableau matriciel => Option de saut de page => Rester ensemble sur une page si possible
Du rapport SSRS. Il essayait de mettre tous les enregistrements sur la même page au lieu de créer plusieurs pages.
Dans mon cas, il me suffisait de déconnecter et de connecter le SSMS. J'ai profilé la requête et la durée d'exécution montrait 1 minute même si la requête elle-même était inférieure à 2 secondes. Redémarrez la connexion et recommencez. Cette fois, la durée indiquait le bon temps d'exécution.
Outre le problème de détection de paramètre, j'ai constaté que SSRS est généralement plus lent lors du traitement côté client que (dans mon cas) les rapports Crystal. Le moteur SSRS ne semble tout simplement pas aussi capable quand il a beaucoup de lignes à filtrer ou à agréger localement. Certes, il s’agit de problèmes de conception d’ensembles de résultats qui peuvent souvent être résolus (mais pas toujours si les détails sont requis pour l’analyse descendante), mais le moteur de génération de rapports le plus humble ... plus mûr ... est plus indulgent.
Dans mon cas, je n'ai pu le résoudre qu'en supprimant le champ intégré [& TotalPages] à partir du bas. Le temps passé de minutes à moins d'une seconde.
Quelque chose d'étrange que je n'ai pas pu déterminer a eu un impact sur le calcul du nombre total de pages.
J'utilisais SSRS 2012.
Utilisez-vous "groupe par" dans la table SSRS?
J'avais un rapport avec 3 champs groupés par et j'ai remarqué que le rapport était exécuté très lentement malgré une requête légère, au point que je ne peux même pas composer de valeurs dans le champ de recherche.
Puis j'ai enlevé les groupements et maintenant le rapport monte en quelques secondes et tout fonctionne en un instant.
Avait le même problème et l'a corrigé en donnant un paramètre par défaut à l'ensemble de données partagé et en mettant à jour cet ensemble de données dans le serveur de rapports.
Un certain nombre de choses que vous pouvez faire, sans exécuter le rapport proprement dit, exécutez simplement le sproc à partir de l'onglet Données des services de génération de rapports. Cela prend-il encore du temps? Une autre option consiste à utiliser SQL Profiler et à déterminer ce qui entre et qui sort du système de base de données.
Une autre chose que vous pouvez faire pour le tester est donc de recréer un rapport simple sans aucun paramètre. Exécutez le rapport et voyez si cela fait une différence. Il se peut que votre rapport RS soit corrompu ou mal formé, ce qui peut rendre le rendu très lent.
Dans notre cas, aucun code n'était requis.
Remarque de notre service d'assistance: "Effacer le paramétrage Internet résoudra ce problème."
Peut-être que cela signifie "cache vide".