Hallo zusammen,

ich habe eine T-SQL Prozedur (MSSQL 2000), in welcher ein Cursor mit FAST-FORWARD Option eine Tabelle durchläuft. Ich habe alle weiteren Anweisungen innerhalb des Cursors entfernt, um dessen Performance zu testen. Er ist leider immernoch zu langsam beim Durchgehen des Resultsets! Das seltsame dabei: Auf dem DB-Server deuten keine mit Perfmon beobachteten Werte auf einen Flaschenhals hin; die CPU-Auslastung ist nur bei 10% (!), es gibt keine Locks etc. Festplatte langweilt sich ebenfalls.

Meine Fragen nun:

- Wieso ist der Cursor so langsam, wenn der Server doch allem Anschein nach genügend Power hätte, den Cursor schneller abzuarbeiten?

- Gibt es einen schnelleren Cursor als "FAST_FORWARD"?

Ich danke euch für jeden Tipp!

Viele Grüße

Matthias

Meine Fragen nun:

- Wieso ist der Cursor so langsam, wenn der Server doch allem Anschein nach genügend Power hätte, den Cursor schneller abzuarbeiten?

grundsätzlich Benutzung von Cursoren ist langsam bzw. langsamer als eine SQL Abfrage, deswegen ist es ratsam immer wenn möglich statt Cursor eine Abfrage zu benutzen.

Interessant wehre das Ausführungsplan von deiner Prozedur, vielleicht lest sich da was optimieren.

Verweist die SELECT-Anweisung auf text-, ntext- oder image-Spalten, oder werden Joins Tables mit Triggern benutzt??

- Gibt es einen schnelleren Cursor als "FAST_FORWARD"?

nein

@bigpoint: Danke Für Dein Feedback.

Interessant wehre das Ausführungsplan von deiner Prozedur, vielleicht lest sich da was optimieren.

Verweist die SELECT-Anweisung auf text-, ntext- oder image-Spalten, oder werden Joins Tables mit Triggern benutzt??

Nein, die Tabelle sieht so aus:

CREATE TABLE [tab] (

	[targetPath] [varchar] (256) COLLATE Latin1_General_CI_AS NOT NULL ,

	[targetName] [varchar] (256) COLLATE Latin1_General_CI_AS NOT NULL ,

	[ds] [smallint] NOT NULL ,

	[value] [float] NOT NULL ,

	[id] [int] IDENTITY (1, 1) NOT NULL ,

	[TimeStamp] [datetime] NOT NULL ,

	CONSTRAINT [PK_tab] PRIMARY KEY  CLUSTERED 

	(

		[id]

	) WITH  FILLFACTOR = 90  ON [PRIMARY] 

) ON [PRIMARY]

GO

In der TSQL-Prozedur mache ich nur einen Cursor auf diese Tabelle auf:

DECLARE CRS_latency CURSOR FAST_FORWARD FOR 

        SELECT targetpath, targetname, ds, value, [id], [timestamp] 

	FROM latency where [id] > @anfangid and [id] <= @endeid


      OPEN CRS_latency 

      FETCH NEXT FROM CRS_latency INTO @targetpath, @targetname, @ds, @value, @id, @timestamp

      WHILE @@FETCH_STATUS = 0


      FETCH NEXT FROM CRS_latency INTO @targetpath, @targetname, @ds, @value, @id, @timestamp

        END --End WHILE

      CLOSE CRS_latency 

      DEALLOCATE CRS_latency

So. Ich mache also nichts im Cursor (testweise), und trotzdem langweilt sich die Server-CPU, ein Flaschenhals ist nicht erkennbar. Idee woran das liegen könnte?

Wie gesagt, Cursor wird immer langsamer als die SQL Abfrage, ist ja auch logisch.

Das CPU sich „lengweit“ ist gar nicht verkehrt, es bedeutet das die abfrage performant ist und der Server halt nicht großartig beschäftigt.

Gruß

bigpoint

Das CPU sich „lengweit“ ist gar nicht verkehrt, es bedeutet das die abfrage performant ist und der Server halt nicht großartig beschäftigt.

;-) Und genau das verstehe ich nicht: Wieso macht er dann nicht einfach schneller?? :confused:

Viele Grüße

Matthias