2
SQL Server 2000: Konflikte beim Zugriff auf Datensätze
Hallo,
ich habe eine Frage zum DB-Zugriff (speziell beim SQL Server 2000 Enterprise).
Sowohl bei Schreib- als auch bei Lesezugriffen gibt es immer wieder Konflikte.
Heißt: sowohl Schreib- als auch Lese-Operationen können nicht durchgeführt werden.
Bei den Schreibzugriffen kommt es zu Konflikten.
Bei den Lesezugriffen zu häufigen Timeouts.
Die Tabellen stehen im Zugriff sowohl von "außen" (Webserver IIS/FTP-Server WS_FTP) als auch von "innen" (VB-Anwendungen, ADO/DAO bzw. OLE DB/ODBC).
Es ist, was die Anzahl der gleichzeitigen Zugriffe betrifft, praktisch kaum eine verlässliche Obergrenze vorhanden.
Heißt: ich muss mit allem rechnen, also, dass x Zugriffe (Lese- und Schreiboperationen) gleichzeitig durchgeführt (besser: angestoßen) werden.
Das gilt nicht nur für Tabellen, sondern auch für einzelne Datensätze.
Was sollte ich bei der Anwendungsentwicklung (ASP "alt", also mit VBScript, ASP.NET, VB, Access VBA usw. usw.) unbedingt beachten, um Schreibkonflikte bzw. Timeouts zu verhindern?
Was sollte ich auf jeden Fall VERMEIDEN?
In welchen Bereichen gibt es grundsätzlich Optimierungspotenzial, was die Performance von SQL-Statements angeht
(Dinge, an die man bei der Entwicklung vielleicht aus Zeitmangel oder aus Nachlässigkeit nicht denkt, bspw. im Bereich Gestaltung von Tabellen/Ausführen von Abfragen aus dem Programmcode)?
Gruß
Thomas
ich habe eine Frage zum DB-Zugriff (speziell beim SQL Server 2000 Enterprise).
Sowohl bei Schreib- als auch bei Lesezugriffen gibt es immer wieder Konflikte.
Heißt: sowohl Schreib- als auch Lese-Operationen können nicht durchgeführt werden.
Bei den Schreibzugriffen kommt es zu Konflikten.
Bei den Lesezugriffen zu häufigen Timeouts.
Die Tabellen stehen im Zugriff sowohl von "außen" (Webserver IIS/FTP-Server WS_FTP) als auch von "innen" (VB-Anwendungen, ADO/DAO bzw. OLE DB/ODBC).
Es ist, was die Anzahl der gleichzeitigen Zugriffe betrifft, praktisch kaum eine verlässliche Obergrenze vorhanden.
Heißt: ich muss mit allem rechnen, also, dass x Zugriffe (Lese- und Schreiboperationen) gleichzeitig durchgeführt (besser: angestoßen) werden.
Das gilt nicht nur für Tabellen, sondern auch für einzelne Datensätze.
Was sollte ich bei der Anwendungsentwicklung (ASP "alt", also mit VBScript, ASP.NET, VB, Access VBA usw. usw.) unbedingt beachten, um Schreibkonflikte bzw. Timeouts zu verhindern?
Was sollte ich auf jeden Fall VERMEIDEN?
In welchen Bereichen gibt es grundsätzlich Optimierungspotenzial, was die Performance von SQL-Statements angeht
(Dinge, an die man bei der Entwicklung vielleicht aus Zeitmangel oder aus Nachlässigkeit nicht denkt, bspw. im Bereich Gestaltung von Tabellen/Ausführen von Abfragen aus dem Programmcode)?
Gruß
Thomas
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 28196
Url: https://administrator.de/contentid/28196
Printed on: April 19, 2024 at 09:04 o'clock
2 Comments
Latest comment
Hi,
frag mich nicht über MS SQL, aber allgemein kann ich dir folgendes raten:
1. Benutze eine transaktionsfähige Datenbank, also eben z.B. MS SQL. Setze dich mit BEGIN/COMMIT/ROLLBACK auseinander.
2. Setze dich mit Tabellen und Row LvL Locking auseinander, so verhinderst du z.B. gleichzeitigen Schreibzugriff
Vermeiden ?
Einfach so drauf los zu arbeiten. Du hast gesagt du kannst nicht sagen, wieviele Benutzer gleichzeitig auf der Datenbank sind. Du solltest dir darüber aber im klaren werden, zumindest einen ca. Wert annehmen und dann 20-30% Performance draufrechnen als Sicherheit. Es helfen die optimiertesten Queries nichts, wenn der Server mit der Benutzeranzahl nicht klarkommt. Mach dir dann evtl. Gedanken über Cluster etc. Über Performanceoptimierung der Queries solltest du normalerweise etwas in der Dokumentation finden. Leg mich da nicht fest, wie gesagt, habs mit MS SQL ned so.
Ansonsten eben Standardoptimierungen nutzen wie z.B, Joins anstatt Subqueries etc.
Hoffe ich konnte dir ein bißchen helfen.
Gruß
Andi
frag mich nicht über MS SQL, aber allgemein kann ich dir folgendes raten:
1. Benutze eine transaktionsfähige Datenbank, also eben z.B. MS SQL. Setze dich mit BEGIN/COMMIT/ROLLBACK auseinander.
2. Setze dich mit Tabellen und Row LvL Locking auseinander, so verhinderst du z.B. gleichzeitigen Schreibzugriff
Vermeiden ?
Einfach so drauf los zu arbeiten. Du hast gesagt du kannst nicht sagen, wieviele Benutzer gleichzeitig auf der Datenbank sind. Du solltest dir darüber aber im klaren werden, zumindest einen ca. Wert annehmen und dann 20-30% Performance draufrechnen als Sicherheit. Es helfen die optimiertesten Queries nichts, wenn der Server mit der Benutzeranzahl nicht klarkommt. Mach dir dann evtl. Gedanken über Cluster etc. Über Performanceoptimierung der Queries solltest du normalerweise etwas in der Dokumentation finden. Leg mich da nicht fest, wie gesagt, habs mit MS SQL ned so.
Ansonsten eben Standardoptimierungen nutzen wie z.B, Joins anstatt Subqueries etc.
Hoffe ich konnte dir ein bißchen helfen.
Gruß
Andi
Hi Andi,
alles klar. Vielen Dank.
Der MS SQL wird bereits geclustert, allerdings nur in einer Failover-Lösung (bringt also nix in Sachen Lastenverteilung).
Ich suche übrigens auch noch nach Tools, um die Performance/Belastung auf Dauer zu protokollieren.
Gruß
Thomas
alles klar. Vielen Dank.
Der MS SQL wird bereits geclustert, allerdings nur in einer Failover-Lösung (bringt also nix in Sachen Lastenverteilung).
Ich suche übrigens auch noch nach Tools, um die Performance/Belastung auf Dauer zu protokollieren.
Gruß
Thomas
