SQL Server 2005 Express - Probleme mit SQL UPDATE und Datenbankgröße

[Bonsai]

Hallo,

bin schon fast verzweifelt.

Erste Frage:

Ich habe eine Datenbank mit mehreren Tabellen und zahlreichen Spalten angelegt. Jede Tabelle hat ca. 500 - 2000 Datensätze. Eine Tabelle hat ca. 43000 Datensätze.

Bei den kleineren Tabellen kann ich mit einer einfachen Update Anweisung einen Datensatz aktualisieren.

z.B.

UPDATE host SET status = 'test' WHERE ip = '112.211.112.11'

Bei der Tabelle mit den 43000 Datensätzen klappt es nicht. Wenn ich die Anweisung in der Management Console direkt als Query ausführe, dann sagt er ewig "Abfrage wird ausgeführt". Diese wird aber nicht beendet. Wenn ich über die ID gehe, dann geht es auch nicht! Hat jmd. vielleicht eine Idee?

Frage 2:

In dem Zusammenhang ist mir auch aufgefallen, dass die Tabelle sehr schnell groß wird. Es sind insgesamt 8 Tabellen mit 147182 Datensätzen. Der Speicherverbrauch liegt bei ca. 540 MB. Kann das sein ??

Hat jmd. ne Idee??

[Bernd Schulz]

Hallo!

Die Größe einer DB hängt ja nicht nur von der Anzahl der Datensätze ab...
Wenn der einzelne Datensatz sehr groß ist wächst die gesamte DB rasant.

Zu Deinem Updateproblem:
Wieviele Zeilen sind den von so einem Update betroffen? (Mach doch mal ein select statt des Updates wie lange dauert das denn?)
Bist du "allein" auf der DB?
Sind Update Trigger auf der Tabelle eingerichtet?
Ist die Tabelle passend indiziert? (wenn du häufig/immer nach IP Updates machst und selektierts sollte da ein Index drauf gesetzt werden)

BYE BERND

[Bonsai]

Vielen Dank für die schnelle Antwort. In dieser Tabelle ist meistens immer nur eine Zeile betroffen. Manchmal können es auch 2,3 oder 4 sein .. Aber nicht Unmengen. Ja ich bin alleine auf der DB. Auch habe ich eine ID Spalte (Index)

Nein es sind keine Trigger eingerichtet
Wie kann ich auf mein IP Feld nen INdex setzten? Es ist vom Datentyp nvarchar

[Bernhard Geyer]

Der Speicherverbrauch liegt bei ca. 540 MB. Kann das sein ??

Kommt darauf an ob die Datenbank schnell sein soll oder nicht. Falls sie schnell sein soll so sollte möglichst viel Daten der Datenbank im Ram liegen, auf jedenfall die Indize die für eine Abfrage benötigt werden.

[Bonsai]

Nein, die Datenbank muss nicht schnell sein. Es ist keine Webanwendung, sonder dient lediglich der Auswertung von Daten.

[Bernhard Geyer]

Bremsen diese 540 MB denn deinen Rechner? Falls nein: Was solls! Las doch Window seine Auslagerungsgeschäft selbständig machen.

[Bonsai]

Nein, das auch nicht.. Es hat mich nur gewundert..
Hat noch jmd. ne Idee zu dem Update Problem?

[Bonsai]

Ok ich habe ein bissle weiter geforscht.. Im Aktivitätsmonitor habe ich gesehen, dass die Update Anweisung von der Select Anweisung blockiert wird.

Aber wie kann ich es sonst machen.. Ich lese mit VB.NET mit einer SQL Select Schleife die Datensätze ein und tätige dann ein Update innerhalb dieser Schleife !!! Wie kann ich das sonst anders regeln?

[Thomas Rith]

Hallo Bonsai,

schreibe es wie folgt:
Select * from IrgendeineTabelle with (nolock)!

Teste mal, ob es dann geht!

Gruß
Thomas

[Bonsai]

Danke Thomas,

jetzt scheint es zu klappen!!!!
Ist der Einsatz von NOLOCK "unsauber" ?? Kann ich es dabei belassen oder sollte ich das Programm nochmal umschreiben??

[Bonsai]

So nochmal zur Größe der Datenbank...

Ich habe in jeder Tabelle zahlreiche Spalten vom Typ nvarchar(max). Fressen die viel Speicher (auch wenn nicht viel drinsteht). Das Problem ist, dass in der einen Zeile mal viel und dann mal wieder nichts steht.

Ich sehe mit der Größe in der Zukunft ein Problem.. SQL Express kann ja nur 4 GB verwalten

[Thomas Rith]

Hi Bonsai,

nochmal zu "Nolock"... Damit hast Du "Dirty Reads"... d.h. Es kann sein, das diese Daten in der Zwischenzeit geändert werden...(Was Du ja auch mit deinem Update wahrscheinlich tust ) , aber eben auch keine Sperre

Gruß
Thomas

[Bonsai]

Ok.. nochmal danke.. damit klappt es wunderbar.. jetzt bin ich noch ein wenig erstaunt mit der Größe der DB .. hätte ich nicht gedacht, dass sie soo schnell so groß wird.. da muss ich nochmal schauen!

[Andreas Kosch]

Hallo,

Ist der Einsatz von NOLOCK "unsauber" ??

in diesem Fall schon ;-)

Normalerweise verwendet man NOLOCK in einer Mehrbenutzerumgebung, bei der der Lesezugriff auf Daten die Schreibzugriffe der anderen Benutzer nicht verhindern soll. Während des Lesens der Daten setzt der SQL Server ein S-Lock (Shared Lock), wobei mehrere Benutzer ein S-Lock gleichzeitig setzen dürfen. Sobald ein Datensatz mindestens 1 S-Lock hat, ist kein Schreibzugriff möglich, da der SQL Server kein X-Lock (Exclusive Lock) auf den Datensatz setzen kann.

Ich lese mit VB.NET mit einer SQL Select Schleife die Datensätze ein und tätige dann ein Update innerhalb dieser Schleife !!!

Die typische Vorgehensweise in ADO.NET besteht darin, sofort nach dem Ausführen der SELECT-Anweisung die Datenbankverbindung wieder zu schließen (genauer gesagt, zurück in den Datenbankverbindungs-Pool zu legen). Der SQL Server entfernt dabei die gesetzten S-Locks wieder von den betroffenen Datensätzen. Wenn die Ergebnismenge der SELECT-Abfrage in einer DataSet-Instanz "offline" zwischengespeichert wurde, kann dort in einer Schleife (wenn diese wirklich notwendig ist) die UPDATE-Anweisung über eine SqlCommand-Instanz ausgeführt werden. In diesem Szenario kann es niemals Sperr-Kollisionen geben. Der Abfrage-Hint WITH NOLOCK ist überflüssig, da die Datenbankverbindung (und somit die Transaktion) sofort wieder beendet wird.

[Bonsai]

Danke Andreas für den Tipp.. An die Sache mit dem Zwischenspeichern in dem DataSet habe ich gar nicht gedacht..