[SSRS] Query designer vreselijk traag

[Verwijderd]

Op mijn werk maken we gebruik van Reporting Services om rapporten te maken voor gebruikers van onze applicatie. Het gaat hier om telecomgegevens. Denk aan gedetailleerde gespreksgegevens zoals het aantal seconden van een gesprek, de kosten die dat met zich meebrengt, gesprekslocatie, etc. Bij een aantal klanten zorgt dit voor een tabel met gespreksgegevens van enkele GB's (de grootste is nu zo'n 9GB groot).

Omdat veel rapportages bestaan uit overzichten met een samenvatting van deze gegevens (veelal management samenvattingen) met een boel sommeringen en berekeningen wordt er gebruik gemaakt van Analysis Services (OLAP), vanwege de snelheid.

Via de applicatie die we aanbieden krijgen gebruikers de mogelijkheid te filteren op een twintigtal zaken (factuurperiode, gebruiker, aansluiting, factuurnummer, gesprekslocatie, etc. etc.) die we dus ook in onze MDX query op het rapport als parameter meegeven.

Het meegeven van veel parameters lijkt echter de query-designer van SSRS ontzettend traag te maken. (wanneer we alle parameters verwijderen in de query designer en hem daarna opnieuw openen staat de query en het resultaat ervan in no-time op het scherm, wanneer we alle parameters toevoegen kan het voorkomen dat als je de query designer opent en/of een query bewerkt en opnieuw opslaat je tien minuten tot een kwartier en soms zelfs langer niks kan doen in SSRS). Wat staat SSRS dan te doen (ik zie geen disk-activity, SQL Profiler laat geen verkeer zien)? En kan hier iets aan gedaan worden waardoor dit sneller werkt? Het toevoegen van één parameter aan alle rapportages is op deze manier een klus van meerdere dagen, terwijl dat volgens mij toch vele malen sneller zou moeten kunnen.

[Mental]

Wat denk je dat de server aan het doen is?
Bij een query zonder parameters: gewoon de hele tabel naar de client spugen; weinig werk.
Bij een query met veel criteria moet de server eerst door de berg data heen walsen om vervolgens pas de output naar de client te sturen.
Tipje: monitor cpu / geheugen / diskgebruik van de server terwijl je simpele en complexe queries draait.. ik gok dat je server ondermaats is voor de hoeveelheid data is zijn database.

[creator1988]

Ditch de designer? De reports zijn gewoon xml, die je in een xml-editor kan aanpassen.

[Verwijderd]

creator1988 schreef op vrijdag 25 juni 2010 @ 11:20:
Ditch de designer? De reports zijn gewoon xml, die je in een xml-editor kan aanpassen.

Ik ben helaas geen expert in het bedenken / schrijven van MDX-query's... De designer is voor mij dus wel een redelijk essentieel onderdeel...

[Verwijderd]

Mental schreef op vrijdag 25 juni 2010 @ 11:16:
Wat denk je dat de server aan het doen is?
Bij een query zonder parameters: gewoon de hele tabel naar de client spugen; weinig werk.
Bij een query met veel criteria moet de server eerst door de berg data heen walsen om vervolgens pas de output naar de client te sturen.
Tipje: monitor cpu / geheugen / diskgebruik van de server terwijl je simpele en complexe queries draait.. ik gok dat je server ondermaats is voor de hoeveelheid data is zijn database.

Het gaat echter niet eens zozeer om de query, want die is wél gewoon snel... Het gaat puur om de query designer! Voor de duidelijkheid, ik geef gewoon lege parameters mee, waardoor de query dus alle waarden gewoon ophaalt. Wat query-performance betreft is er dan ook geen enkel probleem, want dat loopt gewoon. Wanneer ik de query ontdoe van alle parameters (dus parameterloos), dan opent de query-designer wél snel.

Het zit 'm dus écht in de hoeveelheid parameters, maar die heb ik dus wel nodig!

[cariolive23]

Mental schreef op vrijdag 25 juni 2010 @ 11:16:
Wat denk je dat de server aan het doen is?
Bij een query zonder parameters: gewoon de hele tabel naar de client spugen; weinig werk.
Bij een query met veel criteria moet de server eerst door de berg data heen walsen om vervolgens pas de output naar de client te sturen.
Tipje: monitor cpu / geheugen / diskgebruik van de server terwijl je simpele en complexe queries draait.. ik gok dat je server ondermaats is voor de hoeveelheid data is zijn database.

Databases zijn gelukkig ietsjes slimmer dan wat je hier doet voorkomen, een database is geen txt-file waar dom van begin tot eind doorheen wordt gelust. Indexen doen wonderen.

Daarnaast geeft de TS al aan dat hier het probleem niet zit.

[creator1988]

Verwijderd schreef op vrijdag 25 juni 2010 @ 11:48:
[...]


Ik ben helaas geen expert in het bedenken / schrijven van MDX-query's... De designer is voor mij dus wel een redelijk essentieel onderdeel...

Maar het toevoegen van parameters aan bestaande rapporten zou je toch makkelijk moeten kunnen afleiden uit de bestaande queries?

[kevinkrs]

Je kunt toch ook upgraden van programma?
Er bestaan zat programma's dat stukken sneller werken.

[Verwijderd]

kevinkrs schreef op maandag 28 juni 2010 @ 10:32:
Je kunt toch ook upgraden van programma?
Er bestaan zat programma's dat stukken sneller werken.

Zoals? Waar doel je op?

[Verwijderd]

creator1988 schreef op vrijdag 25 juni 2010 @ 13:40:
[...]


Maar het toevoegen van parameters aan bestaande rapporten zou je toch makkelijk moeten kunnen afleiden uit de bestaande queries?

MDX Parameters zitten in de XML code overal verweven... Niet alleen in de query, maar ook in andere secties van de XML. Dit is dus niet even simpel aan te passen in de XML van de RDL file.

[MMUilwijk]

Databases zijn gelukkig ietsjes slimmer dan wat je hier doet voorkomen, een database is geen txt-file waar dom van begin tot eind doorheen wordt gelust. Indexen doen wonderen.

Daarnaast geeft de TS al aan dat hier het probleem niet zit.

Alleen betreft het hier (een) SSAS cube(s), en geen relationele SQL Server database . Monitor eens je SSAS service? Dan kan je kijken of de server voor elke parameter die je toevoegt een MDX query uitvoert. Meestal is dat namelijk wel het geval. En welke versie van SQL Server gebruik je?

[Verwijderd]

MMUilwijk schreef op maandag 28 juni 2010 @ 16:54:
[...]


Alleen betreft het hier (een) SSAS cube(s), en geen relationele SQL Server database . Monitor eens je SSAS service? Dan kan je kijken of de server voor elke parameter die je toevoegt een MDX query uitvoert. Meestal is dat namelijk wel het geval. En welke versie van SQL Server gebruik je?

SQL Server 2008

[Ryceck]

Ik wil dit topic toch even een tikje geven omdat ik wel benieuwd ben of de TS het probleem opgelost heeft of niet. Het verbaast mij namelijk erg dat het werken met query-parameters in een MDX query de hele query-designer overhoopt gooit, dus ben benieuwd wat de oorzaak en eventueel de oplossing is

Een aantal klein vraagjes daarnaast: Ben je nu aan het werken met Query-parameters of met Report-filters? En wat gebeurt er als je de queries welke je schrijft rechtstreeks tegen de OLAP-cube uitvoert in je Management Studio, is het dan ook zo traag? (zo ja, controleer je aggregaties eens)

[LauPro]

Klinkt als een indexatiebug van SSRS oid waardoor hij alle mogelijkheden van elke parameter gaat checken. Zoals gezegd zijn er ook andere query-builders beschikbaar. En anders extern deze kennis inkopen .

[Verwijderd]

Ryceck schreef op maandag 19 juli 2010 @ 15:28:
Ik wil dit topic toch even een tikje geven omdat ik wel benieuwd ben of de TS het probleem opgelost heeft of niet. Het verbaast mij namelijk erg dat het werken met query-parameters in een MDX query de hele query-designer overhoopt gooit, dus ben benieuwd wat de oorzaak en eventueel de oplossing is

Een aantal klein vraagjes daarnaast: Ben je nu aan het werken met Query-parameters of met Report-filters? En wat gebeurt er als je de queries welke je schrijft rechtstreeks tegen de OLAP-cube uitvoert in je Management Studio, is het dan ook zo traag? (zo ja, controleer je aggregaties eens)

Sorry dat ik zo lang niks van me heb laten horen. Vakantie enzo

Bij grote hoeveelheden Query-parameters blijft de boel ontzettend traag bij zowel het openen van de query-designer als het afsluiten van de query designer middels de OK knop (als je Cancel drukt doet ie verder niks, dus dan is het gewoon snel). Het probleem is dus nog niet opgelost.

Ook het uitvoeren van MDX-queries tegen de OLAP-cube gebeurt gewoon vlot. Het zit 'm echt in de hoeveelheid parameters. Ook bewezen door bij een rapport simpelweg alle Query parameters te verwijderen, vervolgens vlamt de query-designer als nooit tevoren over het scherm. Ook bij het opslaan van wijzigingen in de query en dergelijke.

Ik zou het graag eens proberen met zo'n third-party tool. Welke tools adviseren jullie?

[Verwijderd]

Inmiddels de boel ook uitgezet bij Microsoft. Eerst op het forum en vervolgens op connect. Hopelijk gaan ze er een keer naar kijken.

[Darkwand3r3r]

Klinkt mij toch echt dat je indexen op je parameter waardes niet zo goed liggen.
Overigens als de sql profiler niet meer aantoont dat dat hij een query aan het uitvoeren is dan zal hij waarschijnlijk nog aan het renderen zijn.

Kijk ook eens naar het fenomeen parameter sniffing en hoe je dit mogelijk kunt oplossen, als dat het probleem is.

http://www.simple-talk.co...mming/parameter-sniffing/

[ Voor 10% gewijzigd door Darkwand3r3r op 07-10-2010 15:50 ]