Ik heb een SSRS-rapport dat een opgeslagen procedure aanroept. Als ik de opgeslagen procedure rechtstreeks vanuit een queryvenster uitvoer, keert deze binnen 2 seconden terug. Het invullen van dezelfde query vanuit een SSRS-rapport uit 2005 duurt echter maximaal 5 minuten. Dit gebeurt niet alleen bij de eerste run, het gebeurt elke keer. Bovendien zie ik hetzelfde probleem niet in andere omgevingen.
Enig idee waarom het SSRS-rapport zo traag zou werken in deze specifieke omgeving?
Antwoord 1, autoriteit 100%
Bedankt voor de suggesties die hier worden gegeven. We hebben een oplossing gevonden en het bleek te maken te hebben met de parameters. SQL Server produceerde een ingewikkeld uitvoeringsplan toen het werd uitgevoerd vanuit het SSRS-rapport vanwege ‘parameter sniffing’. De tijdelijke oplossing was om variabelen binnen de opgeslagen procedure te declareren en de binnenkomende parameters aan de variabelen toe te wijzen. Vervolgens gebruikte de query de variabelen in plaats van de parameters. Dit zorgde ervoor dat de query consistent werd uitgevoerd, ongeacht of deze werd aangeroepen vanuit SQL Server Manager of via het SSRS-rapport.
Antwoord 2, autoriteit 14%
Voeg dit toe aan het einde van je proces: option(recompile)
Hierdoor wordt het rapport bijna net zo snel uitgevoerd als de opgeslagen procedure
Antwoord 3, autoriteit 12%
Ik zal hieraan toevoegen dat ik hetzelfde probleem had met een niet-opgeslagen procedurequery – alleen een duidelijke select-instructie. Om het op te lossen, heb ik een variabele gedeclareerd in de SQL-instructie van de dataset en deze gelijk gesteld aan de SSRS-parameter.
Wat een vervelende oplossing! Toch willen jullie allemaal bedanken dat jullie me dicht bij het antwoord hebben gebracht!
Antwoord 4, autoriteit 10%
Ik had hetzelfde probleem, hier is mijn beschrijving van het probleem
“Ik heb een winkelprocedure gemaakt die 2200 rijen zou genereren en in bijna 2 seconden zou worden uitgevoerd, maar nadat ik de winkelprocedure vanuit SSRS 2008 had aangeroepen en het rapport had uitgevoerd, is deze eigenlijk nooit uitgevoerd en uiteindelijk moet ik de BIDS (Business Intelligence development Studio) van taakbeheer”.
Wat ik heb geprobeerd: ik heb geprobeerd de SP uit te voeren vanuit de login van reportuser, maar SP werkte ook normaal voor die gebruiker, ik heb Profiler gecontroleerd, maar niets werkte.
Oplossing:
Het probleem is eigenlijk dat hoewel SP het resultaat genereert, de SSRS-engine de tijd neemt om deze vele rijen te lezen en terug te geven.
Dus ik voegde de optie WITH RECOMPILE in SP toe en voerde het rapport uit .. dit is het moment waarop een wonder gebeurde en mijn probleem werd opgelost.
Antwoord 5, autoriteit 5%
Ik had hetzelfde scenario dat zich voordeed..Zeer eenvoudig rapport, de SP (die slechts 1 parameter nodig heeft) duurde 5 seconden om 10K-records terug te brengen, maar het rapport zou 6 minuten duren om te draaien. Volgens profiler en de RS ExecutionLogStorage-tabel besteedde het rapport al zijn tijd aan de query. De opmerking van Brian S. leidde me naar de oplossing..Ik heb gewoon WITH RECOMPILE toegevoegd vóór de AS-instructie in de SP, en nu komt de rapporttijd vrijwel overeen met de SP-uitvoeringstijd.
Antwoord 6, autoriteit 4%
Ik heb simpelweg ‘Herhaal kopkolommen op elke pagina’ gedeselecteerd in de Tablix-eigenschappen.
Antwoord 7, autoriteit 4%
Als uw opgeslagen procedure gekoppelde serversof openquerygebruikt, kunnen ze snel vanzelf werken, maar het duurt lang voordat ze worden weergegeven in SSRS. Enkele algemene suggesties:
- Haal de gegevens rechtstreeks op van de server waar de gegevens zijn opgeslagen door een andere gegevensbron te gebruiken in plaats van de gekoppelde server te gebruiken om de gegevens op te halen.
- Laad de gegevens van de externe server naar een lokale tabel voordat het rapport wordt uitgevoerd, zodat de rapportquery eenvoudig blijft.
- Gebruik een tabelvariabele om eerst de gegevens van de externe server op te halen en vervolgens samen te voegen met uw lokale tabellen in plaats van direct een samenvoeging met een gekoppelde server terug te sturen.
Ik zie dat de vraag is beantwoord, ik voeg dit alleen toe voor het geval iemand hetzelfde probleem heeft.
Antwoord 8, autoriteit 4%
Ik had een probleem met de html-uitvoer van het rapport bij het ophalen van 32000 regels. De query verliep snel, maar de uitvoer naar de webbrowser was erg traag. In mijn geval moest ik “Interactieve paging” activeren om de gebruiker de eerste pagina te laten zien en een Excel-bestand te kunnen genereren. Het voordeel van deze oplossing is dat de eerste pagina snel verschijnt en dat de gebruiker export naar Excel of PDF kan genereren, het nadeel is dat de gebruiker alleen de huidige pagina kan scrollen. Als de gebruiker meer inhoud wil zien, moet hij/zij navigatieknoppen boven het raster gebruiken. In mijn geval accepteerde de gebruiker dit gedrag omdat de export naar Excel belangrijker was.
Om “Interactieve paging” te activeren, moet u op het vrije gebied in het rapportvenster klikken en de eigenschap “InteractiveSize”\ “Hoogte” op rapportniveau in het eigenschappenvenster wijzigen. Stel deze eigenschap in op anders dan 0. Ik heb in mijn geval 8,5 inch ingesteld. Zorg er ook voor dat u de eigenschap “Bij elkaar houden op één pagina indien mogelijk” op Tablix-niveau hebt uitgeschakeld (klik met de rechtermuisknop op de Tablix, dan “Tablix-eigenschappen”, dan “Algemeen”\ “Opties voor pagina-einde”).
Antwoord 9, autoriteit 3%
Ik kwam een soortgelijk probleem tegen met mijn opgeslagen procedure die snel werd uitgevoerd vanuit Management Studio, maar erg traag vanuit SSRS. Na een lange strijd heb ik dit probleem opgelost door de opgeslagen procedure fysiek te verwijderen en opnieuw te maken. Ik ben niet zeker van de logica erachter, maar ik neem aan dat dit komt door de verandering in de tabelstructuur die in de opgeslagen procedure wordt gebruikt.
Antwoord 10, autoriteit 3%
Ik had hetzelfde probleem. Voor mij was het gewoon om de optie uit te vinken:
Tablix-eigenschappen=> Optie voor pagina-einde => Blijf indien mogelijk bij elkaar op één pagina
Van SSRS-rapport. Het probeerde alle records op dezelfde pagina te plaatsen in plaats van veel pagina’s te maken.
Antwoord 11, autoriteit 3%
Afgezien van het probleem met het snuiven van parameters, heb ik ontdekt dat SSRS over het algemeen langzamer is bij de verwerking aan de clientzijde dan (in mijn geval) Crystal-rapporten. De SSRS-engine lijkt gewoon niet zo capabel als hij veel rijen heeft om lokaal te filteren of te aggregeren. Toegegeven, dit zijn ontwerpproblemen met resultaatsets die vaak kunnen worden aangepakt (hoewel niet altijd als de details nodig zijn voor drilldown), maar de meer volwassen… rapportage-engine is vergevingsgezinder.
Antwoord 12, autoriteit 3%
In mijn geval moest ik alleen de SSMS loskoppelen en verbinden. Ik heb de query geprofileerd en de duur van de uitvoering was 1 minuut, hoewel de query zelf minder dan 2 seconden duurt. Herstartte de verbinding en liep opnieuw, deze keer toonde de duur de juiste uitvoeringstijd.
Antwoord 13
Een aantal dingen die u kunt doen, zonder het eigenlijke rapport uit te voeren, voert u gewoon de sproc uit vanuit het gegevenstabblad van rapportageservices. Kost het nog tijd?
Een andere optie is om SQL Profiler te gebruiken en te bepalen wat er in en uit het databasesysteem komt.
Je kunt nog iets doen om het te testen, dus om een eenvoudig rapport te maken zonder parameters. Voer het rapport uit en kijk of het een verschil maakt. Het kan zijn dat uw RS-rapport beschadigd of slecht gevormd is, waardoor de weergave erg traag is.
Antwoord 14
Heb hetzelfde probleem gehad en dit verholpen door de gedeelde dataset een standaardparameter te geven en die dataset bij te werken op de rapportageserver.
Antwoord 15
Gebruik je “groeperen op” in de SSRS-tabel?
Ik had een rapport met 3 gegroepeerd op velden en ik merkte dat het rapport erg langzaam liep ondanks een lichte zoekopdracht, tot het punt waarop ik zelfs geen waarden in het zoekveld kan kiezen.
Toen heb ik de groeperingen verwijderd en nu gaat het rapport binnen enkele seconden omhoog en werkt alles in een oogwenk.
Antwoord 16
Ik heb dit kunnen oplossen door het ingebouwde veld [&TotalPages] onderaan te verwijderen. De tijd die is gedaald van minuten tot minder dan een seconde.
Iets vreemds dat ik niet kon vaststellen, had invloed op de berekening van het totale aantal pagina’s.
Ik gebruikte SSRS 2012.
Antwoord 17
In ons geval was er geen code vereist.
Opmerking van onze helpdesk: “Opruimen van uw internetinstelling zal dit probleem opstellen.”
Misschien betekent dat “cache cache”.