Report Server lange Laufzeiten bei Abfrage mit Parameter

[Doso 77]

Wir nutzen den SQL Server 2012 im Sharepoint 2010 integrierten Modus. Wir greifen über ODBC auf einen Sybase ASE 15 zu. Funktioniert soweit ganz gut. Wir haben nun Abfragen bei denen wir Parameter in in einem Where Like verwenden wollen. Auch das klappt. Nur bei einer etwas komplexeren Abfrage laufen wir damit gegen die Wand. Irgendwas sorgt dafür das die Abfrage dann so lange läuft das kein Ergebnis zurückkommt und der Reportserver die Abfrage auf Grund der Laufzeit killt.

 

Folgende Abfrage direkt klappt, Laufzeit irgendwo max. 1 Minute, 7340 Zeilen:

 

select d.d01ort, d.d01status, d.d01bnr, t.titel, t. titel_avs, t.autor_avs from sisis.d01buch d, sisis.titel_dupdaten t, sisis.titel_verbund tv, sisis.titel_buch_key tbk where d.d01mcopyno=tbk.mcopyno and tbk.katkey=tv.katkey and tbk.katkey=t.katkey and d.d01ort like "0001/8 85-%";

 

Die selbe Abfrage per Parameter dagegen nicht:

 

select d.d01ort, d.d01status, d.d01bnr, t.titel, t. titel_avs, t.autor_avs from sisis.d01buch d, sisis.titel_dupdaten t, sisis.titel_verbund tv, sisis.titel_buch_key tbk where d.d01mcopyno=tbk.mcopyno and tbk.katkey=tv.katkey and tbk.katkey=t.katkey and d.d01ort like @Teilsignatur

 

Wobei dann halt Teilsignatur 0001/8 85-% ist. Ich habe es auch mit 0001/8 85- probiert un das % angehängt, also d.d01ort like @Teilsignatur + "%"

 

Der Bericht ist super simpel, er zeigt einfach die Felder im Select an. Kein gruppieren, summieren, sortieren.

 

Wenn ich mir auf dem ReportServer die View ExecutionLog3 anschaue, in der ja die letzten ausgeführten Bericht protokolliert sind, sehe ich das der Reportserver die meiste Zeit in TimeProcessing hängt.

 

Ich bin etwas ratlos warum nur durch den Parameter plötzlich der Berichtsserver verrückt spielt. Es kommen ja letztlich die selben Daten aus der Datenbank zurück. Jemand eine Idee?

bearbeitet 20. Juli 2016 von Doso

[Sunny61 816]

Hast Du dich bei 1 Minute verschrieben? Soll das 1 Sekunde evtl. heißen?  ;)

 

Auszug aus: http://stackoverflow.com/questions/11152607/using-like-on-a-parameter-variable

 

 

Another option is dynamic SQL:
declare @sql nvarchar(max)
set @sql = 'Select Column1 From Table Where ' + @Variable + 
' Like ''%'' + Column2 + ''%'''
exec (@sql)

 

Dynamisches SQL ist so ziemlich das Letzte, was machen sollte. Dir wird aber möglicherweise nichts anderes übrig bleiben.

 

Im SQL kenn ich eigentlich nur die einfachen ' ' Anführungszeichen. Wird es mit denen besser? Wie ist @Teilsignatur deklariert? Du kannst auf dem MS SQL Server die Abfrage debuggen, lass dir den Inhalt von @Teilsignatur per print @Teilsignatur ausgeben. Evtl. siehst Du dann mehr.

[Doso 77]

Mit Crystal Reports geht diese Abfrage wohl recht flott, ohne Parameter auch. Es ist ein Sybase ASE per ODBC angebunden, da werde ich wenig debuggen können. Bei anderen kleineren Abfragen klappt dieser Syntax.

[Doso 77]

Crosspost: https://social.technet.microsoft.com/Forums/sqlserver/en-US/112435d8-b936-4ca5-9259-842bc45b0b81/parameter-with-like-on-sybase-takes-forever?forum=sqlreportingservices

[Doso 77]

Die Tabelle hat irgendwo 5 Millionen Einträge ist also vermutlich ein Performance Problem. Evtl. ja irgendeine Konvertierungsgeschichte: https://blogs.msdn.microsoft.com/sql_pfe_blog/2009/06/17/possible-performance-implications-when-using-string-parameters-in-reporting-services/

[zahni 566]

Hier steht was:

 

https://rajmsdn.wordpress.com/2010/11/24/to-like-or-not-to-like/

 

Bei Like mit WildCards am Ende macht Sybase wohl gern mal einen Full Table Scan.

[Doso 77]

Das ist wahrscheinlich ein Teil des Problems. Ich habe mal die Timeout Werte massiv in die Höhe gestellt. Dadurch sehe ich das die TimeDataRetrival manchmal bis zu 15 Minuten sind. Das TimeProcessing ist dann 45 Minuten bis zum nächsten Timeout. Wieso das bei manchen Querys recht fix geht, und dann über eine Stunde verstehe ich aber nicht so recht. Da sollten eigtl. die halbwegs selben Daten zurückkommen.

[zahni 566]

Einfach mal beim Hersteller schauen: Mitunter gibt es Bugs, die mit irgendeinem Update behoben sind.

Bei DB2 hatte ich da auch schon Einige und von IBM sogar "Special Builds" bekommen. Reichte vom Crash der Engine bis zum Sterben einzelner Connections, wenn ein bestimmter Index erstellt wurde...

[Doso 77]

Ist ein gehosteter Dienst daher können wir da nicht selber dran basteln. Ist ein Sybase 15.0 und damit schon End of Life. Ist zwar doof aber, mit Crystal Reports hat man bei diesen Abfragen keinerlei Probleme. Gleiche Server, gleiche ODBC Schnittstelle.

bearbeitet 27. Juli 2016 von Doso

[zahni 566]

Wie  gesagt, Ursache kann schon eine andere Art  der gegenseitigen Transaktion sein. Vielleicht kann man die ODBC-Treiber  updaten? Oder Du prüfst, ob es einen OLE DB Provider oder  ADO.NET. Das sollte der Sharepoint können (wobei ich mir bei SP2010 nicht  ganz sicher bin). ODBC  ist aber gefühlt die schlechteste Wahl.

Für den BCS kann ich  übrigens https://lightningtools.com/products/bcs-meta-man-2010-and-2013/  empfehlen.

[Doso 77]

Habe das Query nun anders zusammengebaut, damit geht es in wenigen Sekunden:

 

="select d.d01ort, d.d01status, d.d01bnr, t.titel, t.autor_avs from sisis.d01buch d, sisis.titel_dupdaten t, sisis.titel_verbund tv, sisis.titel_buch_key tbk where d.d01mcopyno=tbk.mcopyno and tbk.katkey=tv.katkey and tbk.katkey=t.katkey and d.d01ort like " + Chr(34) + Parameters!Signaturparam.Value + "%" + Chr(34) + ";"