none
DMV um alle offenen Prepared Statements zu zählen RRS feed

 > 

  • Frage

  • Question
    Anmelden
    0
    Anmelden

    Hallo Zusammen,

    wir haben eine JAVA Client Anwendung dessen ORM hauptsächlich Prepared Statements nutzt (MS SQL 2008 R2).  

    Leider gelingt es uns nicht mit  den SQL Profiler langlaufende Queries zu identifizieren. Da ja immer nur die SP mit dem Handle + Parameter getraced werden. (sp_execute )

    Meine Fragen lauten:

    1. Gibt es eine Möglichkeit im SQL Profiler das tatsächliche SQL Statement bei einem prepared Statement zu tracen?

    2. Gibt es eine DMV welche die Anzahl der offenen Prepared Statements ausgibt? ( Ich vermute dass etliche Statements nicht geschlossen werden)

    Wäre toll wenn mir jemand helfen könnte.

    Gruß

    Stefan

    Montag, 12. September 2016 05:37
    |

Alle Antworten

  • Question
    Anmelden
    1
    Anmelden

    Hallo Stefan,

    schau Dir mal den Blog Artikel an: 4.0 Useful Queries on DMV’s to understand Plan Cache Behavior. Da findet man eine ganze Reihe Abfragen, die die Pläne und ihre Ressourcen-Nutzung auswerten.

    Ansonsten musst Du schauen, ob zum sp_prepare auch ein sp_unprepare existiert, wie zu sehen in: JDBC: When Good Prepared Statements go Bad. Und evtl. den dortigen Ratschlag beherzigen, einmalige Statements ohne Vorbereitung auszuführen, sofern es möglich ist.

    Gruß Elmar

    Montag, 12. September 2016 07:02
    |
  • Question
    Anmelden
    1
    Anmelden

    Hi Stefan,

    mit dem Profiler lässt sich dass durchaus ermitteln. Wenn die JAVA Client Anwendung startet, dann wird irgendwo zu Beginn ein sp_prepare oder sp_prepexec abgesetzt und ein entsprechendes Handle zurückgegeben. In dem prepare oder prepexec wirst Du das eigentliche Statement wiederfinden.

    Die nachfolgenden Aufrufe sind ja, wie Du bereits erkannt hast, sp_execute mit Handle und Parameter.

    Ansonsten schau hier noch mal nach:

    http://stackoverflow.com/questions/6494767/view-sql-prepared-with-sp-prepare

    Hier wird genau Dein Problem beschrieben und diverse Lösungsansätze sind auch vorhanden.

    Wichtig: spiel das ganze, wenn vorhanden, auf einer Testumgebgung durch. Wenn man mit dem Profiler arbeitet und auf Statement Ebene heruntergeht, dann kann das einen Server schon ziemlich ausbremsen.

    Gruß

    Dirk

    May you never suffer the sentiment of spending a day without any purpose


    Montag, 12. September 2016 07:05
    |
  • Question
    Anmelden
    0
    Anmelden

    Hallo

    habt ihr das schon mal mit Extended Events versucht? Oder seit ihr noch auf Prä-SQL 2012 unterwegs?

    Ich habe das Szenario nicht parat zum testen, aber entweder man bekommt es analog zu dem Profiler hin, oder es reicht vielleicht sogar schon die sql_text-Action. Noch eleganter müsste es mit Causality-Tracking gehen.

    Hätte ich einen Repro parat, würde ich das glatt mal testen. Aber das könnt Ihr ja auch ;-)

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Montag, 12. September 2016 07:34
    |
  • Question
    Anmelden
    0
    Anmelden

    Hi Andreas,

    laut Fragensteller handelt es sich um MS SQL 2008...

    Gruß

    Dirk

    May you never suffer the sentiment of spending a day without any purpose

    Montag, 12. September 2016 07:37
    |
  • Question
    Anmelden
    0
    Anmelden

    Ach ja, jetzt sehe ich's.

    Ich meine, das die Events, um die es geht, dort dennoch vorhanden sind. Aber klar, das ist dann nicht mehr ganz so schnell gemacht wie ab 2012.

    Andreas Wolter (Blog | Twitter)
    MCSM: Microsoft Certified Solutions Master Data Platform/SQL Server 2012
    MCM SQL Server 2008
    MVP Data Platform
    www.SarpedonQualityLab.com | www.andreas-wolter.com

    Montag, 12. September 2016 07:40
    |