gespeicherte Prozedur die Ausführung, die lange Zeit in sql server

Ich habe eine Tabelle namens Transaction_tbl mit mehr als 400 000 Einträge. Dies ist die Struktur der Tabelle:

CREATE TABLE [dbo].[Transaction_tbl](
    [transactID] [numeric](18, 0) IDENTITY(1,1) NOT NULL,
    [TBarcode] [varchar](20) NULL,
    [cmpid] [int] NULL,
    [Locid] [int] NULL,
    [PSID] [int] NULL,
    [PCID] [int] NULL,
    [PCdID] [int] NULL,
    [PlateNo] [varchar](20) NULL,
    [vtid] [int] NULL,
    [Compl] [bit] NULL,
    [self] [bit] NULL,
    [LstTic] [bit] NULL,
    [Gticket] [int] NULL,
    [Cticket] [int] NULL,
    [Ecode] [varchar](50) NULL,
    [dtime] [datetime] NULL,
    [LICID] [int] NULL,
    [PAICID] [int] NULL,
    [Plot] [varchar](50) NULL,
    [mkid] [int] NULL,
    [mdlid] [int] NULL,
    [Colid] [int] NULL,
    [Comments] [varchar](100) NULL,
    [Kticket] [int] NULL,
    [PAmount] [numeric](18, 2) NULL,
    [Payid] [int] NULL,
    [Paid] [bit] NULL,
    [Paydate] [datetime] NULL,
    [POICID] [int] NULL,
    [DelDate] [datetime] NULL,
    [DelEcode] [nvarchar](50) NULL,
    [PAICdate] [datetime] NULL,
    [KeyRoomDate] [datetime] NULL,
    [Status] [int] NULL,
 CONSTRAINT [PK_Transaction_tbl] PRIMARY KEY CLUSTERED 
(
    [transactID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

Habe ich einen nicht gruppierten index auf die Locid, dtime Spalte.
Ich habe eine gespeicherte Prozedur wie diese:

ALTER procedure [dbo].[IBS_fetchreleasedinpodiumgridnew]
   @locid INTEGER = NULL
AS BEGIN
   SET NOCOUNT ON
  DECLARE @TodayMinus7Days DATETIME
Declare @krrt integer
Declare @DT integer
   SET @TodayMinus7Days = getdate()-1



SELECT  
       t.TBarcode, t.PlateNo, t.DelEcode,cast(t.Paydate as Time) [REQ],
       datediff(MINUTE, t.PayDate,
             CASE t.Status
                WHEN 3 THEN GETDATE()
                WHEN 4 THEN t.KeyRoomDate
                When 5 THEN  t.KeyRoomDate
                End) as KRRT,

             datediff(MINUTE,t.PayDate,
             CASE t.Status
              WHEN 3 THEN GETDATE()
              WHEN 4 THEN GETDATE()
             WHEN 5 THEN t.DelDate
             END) as DT

   FROM    
       dbo.Transaction_tbl t

   WHERE   

   ( 
       ([status] IN (3,4))
       OR 
       ([status] = 5 AND DATEDIFF(n, DelDate, GETDATE()) <= 3)
   )
   AND locid = 6 AND dtime >= @TodayMinus7Days
   ORDER BY  
       paydate 
       end

meine execution-plan wie dieser:
gespeicherte Prozedur die Ausführung, die lange Zeit in sql server

aber die meisten der Zeit, diese lange Zeit zu führen ..in diesem Fall, wie kann ich verbessern meine Ausführung einer gespeicherten Prozedur Auftritt?

jede andere Methode, die ich verwenden möchten..jede Hilfe ist sehr appriciable.Dank

den Ausführungsplan für die Abfrage zeigt, ist die Sortierung, die lange Zeit..also wenn ich den index auf paydate meine Abfrage-performance steigern?
stattdessen dtime >= @TodayMinus7Days ich code wie diesen:

dtime >= OPTION (optimize for (@TodayMinus7Days))

aber immer Fehler:Falsche syntax bei das Schlüsselwort 'OPTION'.

Sortieren Sie nimmt die längste Zeit, wie kann man aus der Abfrage-plan.
Zu mir; ORDER BY paydate ist der Schuldige hier. Versuchen Sie, erstellen Sie einen index auf paydate (ODER) die Verwendung einer indizierten Spalte in der Reihenfolge von
Gibt es etwas, was du nicht bist uns zu zeigen? Dieser plan schlägt vor, ein inner join, der sollte nicht existieren.
1), Was "nicht mehr als 4 fehlende Einträge" bedeuten. 2) Grob, wie viele Zeilen, die Sie zurückgeben, wenn es "langsam" ist. 3) Wie langsam? e.g, 2 Sek. 20 min, etc. 4) Warum ist @TodayMinus7Days = getdate()-1. 5) Haben Sie versucht, MIT (INDEX (Your_Locid_dtime_Index)) 6) Haben Sie versucht, einen Hinweis ähnlich " - option (optimize for (@TodayMinus7Days = '2000-01-01'))"
Nachdem ich während, ich glaube, ich kann mir vorstellen, dass Ihr wählen Sie ist wahrscheinlich mit der Ihr Locid_dtime index-obwohl die Abfrage-plan Bild nicht sicher -- Wenn man nur die PK und die 1 index, den Sie erwähnen, ist es mit dem index, ich schlug in der Spur.
Den Abfrageplan nicht in der Abfrage-plan, der die gespeicherte Prozedur. Holen Sie sich einen Abfrage-plan auf "exec IBS_fetchreleasedinpodiumgridnew"
wenn jemals zurückgeben, die mehr als 20 Zeilen,wird dieser immer langsamer..um die 30 Sekunden, es s unter ausführen?
getdate()-1 bedeutet, dass die letzten 24 Stunden Daten aus der Tabelle
wenn ich erklärt... OPTION (OPTIMIZE FOR (@TodayMinus7Days UNBEKANNT))..was ist das,

InformationsquelleAutor user3262364 | 2014-05-12

2

Abgesehen von der Optimierung der Abfrage gibt es ein paar Dinge, die ich sofort empfehlen zum verbessern der Leistung einer gespeicherten Prozedur.

Parameter sniffing: Wenn die store-Prozedur wird ein parameter übergeben, es analysiert den Datenbestand, um herauszufinden, was wäre die effizienteste Indizes. Dies ist nützlich, wenn der plan im Cache gespeichert, und wird aus dem Datum, wodurch die gespeicherte Prozedur ausgeführt, die auf eine ineffiziente Ausführungsplan.

Lösung: Re-deklarieren von Parametern, oder optimieren Sie die gespeicherte Prozedur für die unbekannten parameter Werte

Unterdrücken die Zeilenanzahl: Eine der einfachsten Dinge, die Sie tun können, um die Leistung zu erhöhen, eine gespeicherte Prozedur SET NOCOUNT ON. Dies wird verhindern, dass SQL Server das senden von Nachrichten zurück an den client nach der Ausführung jeder Anweisung, die ist nicht erforderlich, für eine gespeicherte Prozedur. Es scheint wie eine kleine Verbesserung, aber die Ergebnisse sind spürbar.

Lösung: SET NOCOUNT ON

Dem snippet unten ist ein Beispiel, wo Sie gehen in Ihr gespeicherte Prozedur. Beachten Sie, dass, wenn Sie re-deklarieren von Parametern, die Sie nicht brauchen, um eine Optimierung für die unbekannt ist, und Umgekehrt.
```
CREATE PROCEDURE dbo.example_proc   
(   
    @USER_PARAM VARCHAR(200)
)
AS
BEGIN

    -- suppress  the number of rows returned
    SET NOCOUNT ON;

    -- Re-declaring the variable will prevent paramater sniffing
    DECLARE @LOCAL_USER_PARAM VARCHAR(200) = @USER_PARAM

    SELECT
        *
    FROM some_table st
    WHERE st.some_column = @LOCAL_USER_PARAM

    -- If you don't re-declare params, you can add this line
    OPTION (OPTIMIZE FOR (@USER_PARAM UNKNOWN))
    --

END 
GO
```
- was meinen Sie mit Re-deklarieren von Parametern, oder optimieren Sie die gespeicherte Prozedur für die unbekannten parameter Werte
- ich mag diese dtime >= OPTION (optimize for (@TodayMinus7Days))..aber immer Fehler
- Verwenden Sie den Parameter wie gewohnt in Ihrer Abfrage, fügen Sie dann die Zeile OPTION (OPTIMIZE FOR (@TodayMinus7Days UNBEKANNT)) nach unten
- warum Sie die Angabe UNBEKANNT
- wenn ich erklärt... OPTION (OPTIMIZE FOR (@TodayMinus7Days UNBEKANNT))..was ist das,
- SQL server kompiliert gespeicherte Prozedur mit einem Ausführungsplan, etc. die ist optimiert für bestimmte Werte. Durch erzählen, es zu optimieren, für die unbekannt ist, das sagt er nicht verwenden Sie eine vorbereitete Ausführung-plan, die veraltet sein können, und optimiert für unterschiedliche Werte haben.
- ok...also wenn ich fügen Sie diesen code..es erhöhen sich meine stored procdure Leistung..
- Richtig. Die performance-Steigerung wird sich ändern, wird für jede gespeicherte Prozedur, je nach Ausführung planen, die Indizierung und vor allem, wo es genannt wird, aus.
InformationsquelleAutor Tsarin
1

Versuchen Sie es mit "with recompile" für mehr geeignet Ausführungsplan basierend auf parameter. In meinem Fall wird es helfen, reduzieren die Zeit von über 1 Stunde zu ein paar Minuten. Hoffe, dass es in Ihrem Fall sowie.
```
exec [dbo].[IBS_fetchreleasedinpodiumgridnew] 1 with recompile
```
InformationsquelleAutor Rawitas Krungkaew

Schreibe einen Kommentar

Du musst angemeldet sein, um einen Kommentar abzugeben.