killerpilz

;-) Und genau das verstehe ich nicht: Wieso macht er dann nicht einfach schneller?? :confused: Viele Grüße Matthias

@bigpoint: Danke Für Dein Feedback. 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?

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