"Select * ... " - Abfrage wird immer langsamer

[Swamison 0]

Guten Morgen :-)

 

Ich bin derzeit am Verzweifeln und weiß echt nicht mehr weiter ...

 

Das folgende Problem tritt nur auf meinem Entwicklungs-Notebook auf. Bei all meinen Kollegen tritt es nicht auf. (nur mal so vorab :-))

Es tritt auch nur auf wenn ich auf unserem dezentralen SQL-Server zugreife. Nicht wenn ich auf meinen localhost SQL-Server zugreife.

 

Wenn ich aus dem SSMS eine einfache Abfrage a la "select * from [tabellenname] where id = X" (Die Tabelle hat gerade mal ca. 1700 Zeilen) absende, benötigt diese beim ersten Mal unter eine Sekunde.

Drücke ich dann F5 (nochmaliges Ausführen) benötigt die Abfrage ca. 2 Sekunde, nochmal F5 dann sind es 5-6 Sekunden, nochmal F5 dann sind es ca. 17 Sekunden usw. Irgendwann kommt dann ein "timeoute". Das Interessante ist, dass zum Beispiel die Abfrage "select id from [tabellenname] where id = X", oder "select id,name from [tabellenname] where id = X" dieses Problem nicht hat.

 

Ich habe das Problem schon so weit "analysiert" dass es wohl irgendwas mit den Spaltennamen zu tun haben muss. Ich komme darauf da ich dies ausprobiert habe:

Das hier ist die Tabelle:

CREATE TABLE [dbo].[pruefart](

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

[name] [nvarchar](100) NULL,

[kundenkundeid] [int] NULL,

[pruefintervall] [int] NULL CONSTRAINT [DF_pruefart_pruefintervallmtl] DEFAULT ((0)),

[pruefunganlegenart] [int] NULL CONSTRAINT [DF_pruefart_pruefunganlegenart] DEFAULT ((0)),

[pruefungsEK] [float] NULL CONSTRAINT [DF_pruefart_pruefungsEK] DEFAULT ((0)),

[pruefungsVK] [float] NULL CONSTRAINT [DF_pruefart_pruefungsVK] DEFAULT ((0)),

[pruefintervallEinheitID] [int] NULL,

[visible] [int] NULL CONSTRAINT [DF_pruefart_visible] DEFAULT ((1)),

[aufgabengruppeID] [int] NULL,

[beschreibung] [nvarchar](50) NULL,

[connectorID] [int] NULL,

[ersatzteileBeiAuftragsabwicklung] [int] NULL CONSTRAINT [DF_pruefart_ersatzteileBeiAuftragsabwicklung] DEFAULT ((0)),

[auftragsaufgabendatenBeiAuftragsabwicklung] [int] NULL CONSTRAINT [DF_pruefart_auftragsaufgabendatenBeiAuftragsabwicklung] DEFAULT ((0)),

[fehlerbeschreibungenBeiAuftragsabwicklung] [int] NULL CONSTRAINT [DF_pruefart_fehlerbeschreibungenBeiAuftragsabwicklung] DEFAULT ((0)),

[lohnkostenBeiAuftragsabwicklung] [int] NULL CONSTRAINT [DF_pruefart_lohnkostenBeiAuftragsabwicklung] DEFAULT ((0)),

[aufgabendokumentDemInventarHinterlegbar] [int] NULL CONSTRAINT [DF_pruefart_aufgabendokumentDemInventarHinterlegbar] DEFAULT ((0)),

[automatischeAuftragsConnectorAbwicklung] [int] NULL,

[auftragserstellungslieferscheinNichtAnzeigen] [int] NULL,

[ohneERDLLieferscheinAbschliessen] [int] NULL,

[inventarVerschrottenMoeglich] [int] NULL,

[lohnkostenBeiAuftragsabwicklungAlsDetaillierteListe] [int] NULL,

[lohnkostenBeiAuftragsabwicklungAlsEinzelwert] [int] NULL,

[inventarspezifischePruefarteigenschaften] [int] NULL,

[inventarspezifischePruefarteigenschaftenKopfpfad] [nvarchar](100) NULL,

[CRfuerAufgabenPDFEmail] [nvarchar](50) NULL,

[inventarspezifischePruefarteigenschaftenBerichtsfuss] [nvarchar](500) NULL,

[standardtdlReferenznummer] [int] NULL,

[NIOEmailAdresse] [nvarchar](100) NULL,

[taetigkeit] [nvarchar](50) NULL CONSTRAINT [DF_pruefart_taetigkeit] DEFAULT (''),

[Kostenvoranschlagabwicklung] [int] NULL CONSTRAINT [DF_pruefart_Kostenvoranschlagabwicklung] DEFAULT ((0)),

[KostenvoranschlagEmailadresse] [nvarchar](100) NULL,

[createdate] [datetime] NULL CONSTRAINT [DF_pruefart_createdate] DEFAULT (getdate()),

[updateDate] [datetime] NULL,

CONSTRAINT [PK_pruefung] PRIMARY KEY CLUSTERED

(

[id] ASC

)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 90) ON [PRIMARY]

) ON [PRIMARY]

 

Benenne ich in einer Select Abfrage alle Spalten per Name, dann habe ich den gleichen Effekt wie bei der "select *" Abfrage.

Nun was spannendes. Folgende Abfrage wird ganz normal ausgeführt (zeigt das Problem also nicht):

SELECT [id],
--[name],
[kundenkundeid],
[pruefintervall],
[pruefunganlegenart],
[pruefungsEK],
[pruefungsVK],
[pruefintervallEinheitID],
[visible],
[aufgabengruppeID],
[beschreibung],
[connectorID]
,[fehlerbeschreibungenBeiAuftragsabwicklung]
,[ohneERDLLieferscheinAbschliessen]
,[CRfuerAufgabenPDFEmail]
,[inventarspezifischePruefarteigenschaftenBerichtsfuss]
,[standardtdlReferenznummer]
,[NIOEmailAdresse]
,[taetigkeit]
,[Kostenvoranschlagabwicklung]
,[KostenvoranschlagEmailadresse]
,[createdate]
,[updateDate]
FROM [dbo].[pruefart] where id = 1655

 

Nehme ich nun die Spalte "name" hinzu (durch das entfernen von "--") habe ich den gleichen Effekt wie bei der "select *" Abfrage. Sie wird nach jedem nochmaligem Ausführen immer langsamer. Den gleichen Effekt habe ich auch, wenn ich per Visual Studio auf die Datenbank zugreife. (Egal welche Version).

Und nun der Hammer: Ändere ich die Spaltennamen ab der Spalte 'name' in a,b,c,d,e,f,... und mache dann ein "select *" tritt das Problem nicht auf. Auch andere Tabellen mit weniger Spalten (bzw. kürzeren Spaltennamen) zeigen diesen Effekt nicht. Andere Tabellen mit genauso viel oder mehr Spalten (und diesbezüglich längerer Spaltennamen) zeigen dieses Problem auch.

 

Ich nutze Windows 7 Pro / VS 2003 und VS 2010 / SQL-Server 2012 SP2

Unser dezentraler SQL-Server nutzt Windows Server 2012R2 / SQL Server 2012 SP2

 

Folgendes habe ich bisher versucht:

- Netzwerkkartentreiber aktualisiert, auch ältere verwendet

- Alle Windowsupdates deinstalliert die kurz vor dem Auftreten des Problems installiert wurden

- Diverse WAN / LAN Netze ausprobiert (Zu Hause, im Büro, per UMTS)

- An den Netzwerkkarteneinstellungen wohl ziemlich alles verstellt was geht (z.B. "IPv4 Prüfsummenabladung" deaktiviert etc., in Anlehnung an jemanden der das gleiche Problem hatte: http://stackoverflow.com/questions/7869824/net-to-remote-sql-server-slow-on-one-machine-not-the-other)

- Firewall an/abgestellt

- Virenbefall kann ausgeschlossen werden (diverse Scanner ausprobiert, auch z.B. Ad-Aware)

- Per SmartSniff den Traffic auf Port 1433 angeschaut, sieht okay aus.

 

Es muss wohl etwas an meinem Notebook sein, da dieses Problem bei anderen nicht auftritt.

Ich habe aber im Netz bisher nichts gefunden und hoffe nun, dass vielleicht einer von euch mir einen Tipp geben kann oder vielleicht gar schon mal von so einem Problem (und dessen Lösung) gehört/gelesen hat.

 

Was ich heute noch probieren werde ist meine Windows 7 Version mittels der Installations-CD zu "reparieren". Mal schauen.

 

Gruß

Thomas