Announcement

Collapse
No announcement yet.

Timeout in StoredProcedure ??

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • Timeout in StoredProcedure ??

    Hallo zusammen,

    ich habe ein Phänomen bei dem ich nicht mehr weiterkomme. Ich kann es auch nicht "reproduzieren".

    Wir haben eine SP die immer wieder mal "aussetzer" hat und einen Fehler wirft:

    ALTER PROCEDURE [td].[mySP] (@domain as nvarchar(255), @project as nvarchar(255))
    AS
    BEGIN

    SET NOCOUNT ON;
    Declare @Database as nvarchar(255);
    Declare @sql as nvarchar(max);
    set @sql = '';

    select @Database = p.[db_name]
    from projects p,
    database2.PROJECTS qp
    where domain = @domain
    and name = @project
    and p.name = qp.PROJECT_NAME
    and p.domain = qp.DOMAIN_NAME;

    if( @Database is null)
    begin
    raiserror('Project not configured in Database xy ', 16, 1);
    end

    END

    Problem:
    im Logfile von openjpa-2.1.2 findet sich immer wieder mal der Eintrag aus dem RAISEERROR der Prozedur.
    Allerdings dürfte das nicht sein, da nachweislich der Select funktioniert (die gesuchten Projekte/Domain also vorhanden sind).
    Sie werden auch nicht temporär entfernt o.ä. sodass der select nicht treffen könnte. Definitiv nicht.

    Ebenso sind laut Logfile bspw. um 11 Uhr die Aufrufe OK, um 11.05 nicht und um 11.15 wieder falsch.
    Der SQL Server ist allerdings oft "auf Anschlag" (CPU, Speicher auf 100%)

    An der Implementierung von openjpa kann es doch auch nicht liegen oder? Die Fehlermeldung im Log stammt ja eindeutig aus der Prozedur
    ("Project not configured in Database xy") .


    Kann der Select innerhalb der SP zu einem Timeout führen, sodass der Variable eben nichts zugewiesen wird?
    Allerdings ist kein executon-timeout auf dem Server oder der DB eingestellt.

    Vielen Dank im Voraus

  • #2
    Originally posted by tasmania View Post
    Allerdings dürfte das nicht sein, da nachweislich der Select funktioniert (die gesuchten Projekte/Domain also vorhanden sind).
    Sie werden auch nicht temporär entfernt o.ä. sodass der select nicht treffen könnte. Definitiv nicht.
    Hallo, ich würde die Aufrufparameter, einmal mit protokollieren. Ansonsten könnte ich mir bei dieser Aussage nicht so recht sicher sein. Vielleicht wird die SP irgendwo mit NULL Werten aufgerufen?
    Vielleicht gibt es doch ein Projekt, das nicht konfiguriert ist?
    Sicher wäre die ganze Procedure damit auch ein wenig aussagekrätiger...

    [highlight=sql]
    raiserror('Project '+IsNull(@project,'?Projekt?') ' not configured in Database '+ isNull(@domain,'?Domain?'), 16, 1);
    [/highlight]

    Eventuell sind die zugrundeliegenden Tabellen irgendwie gelockt, ein NOLOCK - Hint wäre vielleicht auch hilfreich

    [highlight=sql]
    ...
    from projects p NOLOCK,
    database2.PROJECTS qp NOLOCK
    ...

    [/highlight]

    Allerdings würde es dann eher "klemmen" als mit NULL zu beenden.


    Viel Erfolg
    Tino
    Ich habs gleich!
    ... sagte der Programmierer.

    Comment


    • #3
      Ich würde tinof zustimmen, da hängt nichts, sondern das Select liefert gemäß unpassender Abfrageparaneter ein leeres Ergebnis.

      Neben der Protokollierung der Parameter empfiehlt sich ein wohlwollender Blick auf den Datenbestand, der durch das Select abgefragt wird. Ist das alles mit Constraints wassericht abgesichert oder gibt es Leichen, Dubletten, ..?

      Wenn die Datenbasis sauber ist, wäre zu klären, woher falsche Parameter kommen.
      Da offenbar mit Textjoins und Parametern gearbeitet wird, fallen mir da so Dinge ein wie Leerzeichen am Ende usw...
      Gruß, defo

      Comment


      • #4
        Zeigst du uns auch die wirkliche Procedure? Die @sql Variable sieht verdächtig danach aus als wäre eigentlich irgendeine Form von dynamischen sql beteiligt. Wenn das sql dynamisch ausgeführt wird und du aus diesem Context die @Database heraustransportierst können da auch ganz andere Sachen schiefgehen.

        Comment

        Working...
        X