4
MS SQL 2000 auf Windows Server 2003 einzelne Tabellen in Datenbanken machen Probleme
MS SQL 2000
Windows Server 2003
Enterprise Manager oder Query Analyzer
Ich greife per Enterprise Manager oder SQL Query Analyzer auf die Datenbanken zu und habe mit unserem Datenbankserver zur Zeit leider ganz schön Probleme.
Wenn ich mit dem Enterprise Manager in bestimmten Datenbanken in einzelnen Tabellen mir alles anzeigen lasse (also im Endeffekt "Select * from Tabelle") und im Ergebnisbereich dann alles drin habe und ein einziges Feld ändern möchte, macht er nicht mit, sondern gibt mir ne Fehlermeldung aus, dass die Ergebnisgruppe zu groß sei und es deshalb ziemlich lang dauern würde, bis er dies erledigt hat.
Bei nem Select mit TOP 100 oder auch mit TOP1000 führt er die Änderung sofort durch.
Da ich befürchtet hatte, es könnte am Platz auf der Festplatte liegen, hab ich den Speicherplatz kontrolliert, aber da sind noch locker um die 30 GB frei, also definitiv ausreichend Platz.
Die Transaktions-Logs hab ich per Befehlseingabe im SQL Query Analyzer verkleinert und bis auf die problembelastete Datenbank selbst konnte ich über den Enterprise Manager auch die anderen Datenbanken verkleinern. Die DB mit der größeren problembehafteten Tabelle konnte ich nicht verkleinern, die Datenbank selbst ist ca. 3 GB groß, hat intern aber ca. 33% freien Speicher. Sie ließe sich theoretisch also doch ziemlich deutlich verkleinern. Praktisch läßt sie sich aber nicht mal um 1 MB verkleinern, sondern schickt den Enterprise Manager ins Nirvana.
Beim Count auf die größere Tabelle, war das Ergebnis fast 120.000 Datensätze (in der Tabelle ist in ettlichen Feldern NULL zugelassen und auch einige ntext-Felder sind enthalten), bei ner anderen (kleineren) Tabelle, die derzeit die gleichen Probleme bereitet, sind es gerade mal 20.000 Datensätze (also nur 1/6 der Datensätze der größeren Problem-Tabelle) und es sind nicht mal ntext-Felder in dieser Tabelle vorhanden.
Hat mir jemand nen Tipp, zur Behebung der Probleme?
Hat mir jemand nen Tipp, welche Möglichkeit ich in Zukunft habe, um solche Probleme zu verhindern?
Was sind in so nem Fall grundlegende Fehler, die ich vermeiden kann?
Wie sieht es bei derartig großen Tabellen mit nvarchar-, text- und ntext-Feldern aus, in wiefern können die sich negativ auf die Performance auswirken?
Ist es sinnvoll NULL zuzulassen oder lieber gleich von vornherein alle Felder mit nem Wert vorbelegen?
Den SQL Profiler hab ich zwar schon gefunden, aber damit umgehen kann ich noch nicht. Hat mir hierzu jemand nen Tipp, auf was ich den SQL Profiler bei derartigen Performance-Problemen ansetzen soll?
Vielen Dank und liebe Grüßle
Saskia
Windows Server 2003
Enterprise Manager oder Query Analyzer
Ich greife per Enterprise Manager oder SQL Query Analyzer auf die Datenbanken zu und habe mit unserem Datenbankserver zur Zeit leider ganz schön Probleme.
Wenn ich mit dem Enterprise Manager in bestimmten Datenbanken in einzelnen Tabellen mir alles anzeigen lasse (also im Endeffekt "Select * from Tabelle") und im Ergebnisbereich dann alles drin habe und ein einziges Feld ändern möchte, macht er nicht mit, sondern gibt mir ne Fehlermeldung aus, dass die Ergebnisgruppe zu groß sei und es deshalb ziemlich lang dauern würde, bis er dies erledigt hat.
Bei nem Select mit TOP 100 oder auch mit TOP1000 führt er die Änderung sofort durch.
Da ich befürchtet hatte, es könnte am Platz auf der Festplatte liegen, hab ich den Speicherplatz kontrolliert, aber da sind noch locker um die 30 GB frei, also definitiv ausreichend Platz.
Die Transaktions-Logs hab ich per Befehlseingabe im SQL Query Analyzer verkleinert und bis auf die problembelastete Datenbank selbst konnte ich über den Enterprise Manager auch die anderen Datenbanken verkleinern. Die DB mit der größeren problembehafteten Tabelle konnte ich nicht verkleinern, die Datenbank selbst ist ca. 3 GB groß, hat intern aber ca. 33% freien Speicher. Sie ließe sich theoretisch also doch ziemlich deutlich verkleinern. Praktisch läßt sie sich aber nicht mal um 1 MB verkleinern, sondern schickt den Enterprise Manager ins Nirvana.
Beim Count auf die größere Tabelle, war das Ergebnis fast 120.000 Datensätze (in der Tabelle ist in ettlichen Feldern NULL zugelassen und auch einige ntext-Felder sind enthalten), bei ner anderen (kleineren) Tabelle, die derzeit die gleichen Probleme bereitet, sind es gerade mal 20.000 Datensätze (also nur 1/6 der Datensätze der größeren Problem-Tabelle) und es sind nicht mal ntext-Felder in dieser Tabelle vorhanden.
Hat mir jemand nen Tipp, zur Behebung der Probleme?
Hat mir jemand nen Tipp, welche Möglichkeit ich in Zukunft habe, um solche Probleme zu verhindern?
Was sind in so nem Fall grundlegende Fehler, die ich vermeiden kann?
Wie sieht es bei derartig großen Tabellen mit nvarchar-, text- und ntext-Feldern aus, in wiefern können die sich negativ auf die Performance auswirken?
Ist es sinnvoll NULL zuzulassen oder lieber gleich von vornherein alle Felder mit nem Wert vorbelegen?
Den SQL Profiler hab ich zwar schon gefunden, aber damit umgehen kann ich noch nicht. Hat mir hierzu jemand nen Tipp, auf was ich den SQL Profiler bei derartigen Performance-Problemen ansetzen soll?
Vielen Dank und liebe Grüßle
Saskia
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 73584
Url: https://administrator.de/contentid/73584
Ausgedruckt am: 23.11.2024 um 00:11 Uhr
4 Kommentare
Neuester Kommentar
Moin Saskia,
trotz Deiner ausführlichen Beschreibung sind die Performancefresser natürlich noch nicht aus der Ferne lokalierbar.
So weit die schlechte Nachricht.
Aber die gute Nachricht: An ein paar Stellen können wir uns vielleicht rantasten.
Das tut man/frau auch nicht.
Alles (oder sehr viel) anzeigen...OKAY.
Aber dann bitte mit
..was bedeutet, dass der Server keine Ressourcen dafür verbraten soll zu prüfen, ob die angezeigten Sätze auf dem Bildschirm immer noch identisch sind mit den in dieser Nanosekunde in der Datenbank befindlichen. Oder ob die gerade ein anderer geändert hat.
Die Unterscheidung, ob die Daten einmalig geliefert werden oder sich permanent aktualisieren, während das Abgebnis Deines Select auf dem Bildschirm scheinbar statisch aussieht - das ist ein Ressourcenfresser Nr. 1.
[Nachteil: kann natürlich sein, dass wirklich in der Datenbank schon ein anderer geändert hat...]
Deshalb mach -nach einem "Select alleswogibt FOR BROWSE" dann gezielt ein "Select Teilmenge/einSatz" mit einem gedachten "FOR UPDATE" dahinter.
Zu den NULLABLE/NULLABLE WITH DEFAULT/NOT NULLABLE-Feldern:
Klar, wann immer es geht NOT NULL with default.
Und jeder Applikationsschreiber, der von Dir eine Tabelle mit NULLABLE-Feldern en masse verlangt, sollte sofort zum persönlichen Beratungsgespräch einbestellt werden.
Aber ganz lieb, denn die Jungs und Mädels haben die Applikationsbrille auf und machen sich keine Gedanken um Datenbankperformance, haben nicht das Knowhow...und brauchen das auch nicht. Aber die hören in Regel zu und verstehen das. Meine Erfahrung.
Aber das Hauptproblem,das ich bei Dir vermute, sind eher
Für die Punkte 1,2 und 4 ist sinnvoll, entweder mich (oder einen beliebigen anderen Biber) zum Cappuccino einzuladen oder aber sich mit einem SQL-Profiler/Explain/Monitor auseinanderzusetzen.
"Komme nicht klar mit dem Tool" hilft da nicht - die Alternative ist raten. Bzw Trial & Error.
Von anderen DB-Systemen weiß ich, dass es da durchaus vom Anbieter selbst Schulungen/Seminare gibt wie "Oracle SQL Tuning and Monitoring".
Hat M$ da nichts im Angebot?
Grüße
Biber
[Edit Nachtrag]
ich wusste doch, dass ich neulich mal was Nettes von M$ gelesen hatte:
[/Edit]
trotz Deiner ausführlichen Beschreibung sind die Performancefresser natürlich noch nicht aus der Ferne lokalierbar.
So weit die schlechte Nachricht.
Aber die gute Nachricht: An ein paar Stellen können wir uns vielleicht rantasten.
Wenn ich ...in einzelnen Tabellen mir alles anzeigen lasse (also im Endeffekt "Select * from Tabelle") und im Ergebnisbereich dann alles drin habe...
Das tut man/frau auch nicht.
Alles (oder sehr viel) anzeigen...OKAY.
Aber dann bitte mit
Select * from Tabelle FOR BROWSE..was bedeutet, dass der Server keine Ressourcen dafür verbraten soll zu prüfen, ob die angezeigten Sätze auf dem Bildschirm immer noch identisch sind mit den in dieser Nanosekunde in der Datenbank befindlichen. Oder ob die gerade ein anderer geändert hat.
Die Unterscheidung, ob die Daten einmalig geliefert werden oder sich permanent aktualisieren, während das Abgebnis Deines Select auf dem Bildschirm scheinbar statisch aussieht - das ist ein Ressourcenfresser Nr. 1.
[Nachteil: kann natürlich sein, dass wirklich in der Datenbank schon ein anderer geändert hat...]
Deshalb mach -nach einem "Select alleswogibt FOR BROWSE" dann gezielt ein "Select Teilmenge/einSatz" mit einem gedachten "FOR UPDATE" dahinter.
Zu den NULLABLE/NULLABLE WITH DEFAULT/NOT NULLABLE-Feldern:
Klar, wann immer es geht NOT NULL with default.
Und jeder Applikationsschreiber, der von Dir eine Tabelle mit NULLABLE-Feldern en masse verlangt, sollte sofort zum persönlichen Beratungsgespräch einbestellt werden.
Aber ganz lieb, denn die Jungs und Mädels haben die Applikationsbrille auf und machen sich keine Gedanken um Datenbankperformance, haben nicht das Knowhow...und brauchen das auch nicht. Aber die hören in Regel zu und verstehen das. Meine Erfahrung.
Aber das Hauptproblem,das ich bei Dir vermute, sind eher
- fehlende oder ungeschickte Indices
- eventuell fehlende Partionierung (andererseits...die Tabellchen sind ja eher fipsig bei Dir)
- ein zu kleiner Cache
- und (nicht hauen jetzt) ungeschickte SQL-Abfragen
Für die Punkte 1,2 und 4 ist sinnvoll, entweder mich (oder einen beliebigen anderen Biber) zum Cappuccino einzuladen oder aber sich mit einem SQL-Profiler/Explain/Monitor auseinanderzusetzen.
"Komme nicht klar mit dem Tool" hilft da nicht - die Alternative ist raten. Bzw Trial & Error.
Von anderen DB-Systemen weiß ich, dass es da durchaus vom Anbieter selbst Schulungen/Seminare gibt wie "Oracle SQL Tuning and Monitoring".
Hat M$ da nichts im Angebot?
Grüße
Biber
[Edit Nachtrag]
ich wusste doch, dass ich neulich mal was Nettes von M$ gelesen hatte:
Die folgenden Tabellenhinweise sind mit und ohne WITH-Schlüsselwort zulässig: NOLOCK, READUNCOMMITTED, UPDLOCK, REPEATABLEREAD, SERIALIZABLE, READCOMMITTED, FASTFIRSTROW, TABLOCK, TABLOCKX, PAGLOCK, ROWLOCK, NOWAIT, READPAST, XLOCK und NOEXPAND.
---> von der MSDN-Seite SQL Server 2005-Onlinedokumentation, aber auch bei Dir relativ passend. Inclusive der Verweise zu Sperrverhalten und Transaktionen. meld Dich, wenn Du es durch hast..[/Edit]
Hallo Biber,
Danke für Deine Antwort. Ich hab ja auch nicht erwartet, dass Ihr mir mein Problem vollständig aus der Ferne löst, sondern nur, dass ich irgendwo ein paar Infos und Ideen herbekomme, welche Möglichkeiten ich habe, das Problem in Etappen einzugrenzen und nach und nach auszuschalten.
Beim Enterprise Manager gibt es ja bei den Tabellen beim Rechten Mausklick "Tabelle öffnen" -> "Alle Zeilen zurückgeben" und da macht er eben leider automatisch immer den "Select *" ohne das von Dir angsprochene "for browse". Hast Du ne Ahnung, ob es da ne Möglichkeit gibt, dass man das irgendwie voreinstellen kann, so dass das immer nur als "for browse" geöffnet wird und man dann entsprechend den Server weniger stark belastet?
Die NULLABLE-Felder werde ich also nach und nach alle verbannen und neue Datenbanktabellen bekommen einfach keine NULLABLE-Felder mehr, sondern immer nen Default.
Ich hab nicht gesagt, dass ich mit dem SQL-Profiler nicht klar komme, sondern nur, dass ich mich damit noch nicht außeinandergesetzt habe und dass ich gern ein paar Tipps hätte, mit denen ich evtl. um nen Teil des Trial & Error herumgekommen wäre, ist doch auch verständlich, oder?
Und für Schulungen braucht man doch Zeit, oder etwa nicht? Und Zeit hab ich irgendwie nie.
Und Danke für den Link zur Online-Doku, die werd ich mir in den nächsten Tagen mal zu gemüte führen, nachdem ich die ersten Schritte zur Behebung des Problems in Angriff genommen habe.
Danke und liebe Grüßle in den Norden
Saskia
Danke für Deine Antwort. Ich hab ja auch nicht erwartet, dass Ihr mir mein Problem vollständig aus der Ferne löst, sondern nur, dass ich irgendwo ein paar Infos und Ideen herbekomme, welche Möglichkeiten ich habe, das Problem in Etappen einzugrenzen und nach und nach auszuschalten.
Beim Enterprise Manager gibt es ja bei den Tabellen beim Rechten Mausklick "Tabelle öffnen" -> "Alle Zeilen zurückgeben" und da macht er eben leider automatisch immer den "Select *" ohne das von Dir angsprochene "for browse". Hast Du ne Ahnung, ob es da ne Möglichkeit gibt, dass man das irgendwie voreinstellen kann, so dass das immer nur als "for browse" geöffnet wird und man dann entsprechend den Server weniger stark belastet?
Die NULLABLE-Felder werde ich also nach und nach alle verbannen und neue Datenbanktabellen bekommen einfach keine NULLABLE-Felder mehr, sondern immer nen Default.
- Bzgl. den Indices das kann gut hinkommen, da hab ich mich bisher noch nicht wirklich mit beschäftigt, da ich die Administration eigentlich immer nur eher nebenher mache.
- In wiefern bei ner DB-Tabelle Partitionierung erfoderlich ist oder gemacht wird? Davon hab ich bisher noch überhaupt keine Ahnung, da ich mich damit bisher wie gesagt auch noch nicht außeinandergesetzt habe. Dass meine Tabellen fiepsig sind, das tut gut, denn dann brauche ich an der Tabellengröße definitiv nicht nach der Lösung des Problems zu suchen.
- Bzgl. dem Cache, der ist glaube ich nicht zu klein, da die Serverauslastung relativ gering ist.
- keine Angst, ich hau Dich nicht, aber dass die SQL-Abfragen teilweise mehr als ungeschickt sind, glaub ich Dir sofort, denn es wird ja immer und überall nur erweitert, aber nirgends alter Kram überarbeitet und "früher" hat man sich über manche Performance-Probleme leider auch noch gar keine Gedanken gemacht, überall wurde einfach nur "Select * from", statt "Select benötigte Tabellenfelder from" gemacht, ... ich weiß, eigentlich müßte da ne ganze Menge alter Kram überarbeitet werden. Aber wenn immer die Zeit fehlt, ...
Ich hab nicht gesagt, dass ich mit dem SQL-Profiler nicht klar komme, sondern nur, dass ich mich damit noch nicht außeinandergesetzt habe und dass ich gern ein paar Tipps hätte, mit denen ich evtl. um nen Teil des Trial & Error herumgekommen wäre, ist doch auch verständlich, oder?
Und für Schulungen braucht man doch Zeit, oder etwa nicht? Und Zeit hab ich irgendwie nie.
Und Danke für den Link zur Online-Doku, die werd ich mir in den nächsten Tagen mal zu gemüte führen, nachdem ich die ersten Schritte zur Behebung des Problems in Angriff genommen habe.
Danke und liebe Grüßle in den Norden
Saskia
Beim Count auf die größere
Tabelle, war das Ergebnis fast 120.000
Datensätze (in der Tabelle ist in
ettlichen Feldern NULL zugelassen und auch
einige ntext-Felder sind enthalten), bei ner
anderen (kleineren) Tabelle, die derzeit die
gleichen Probleme bereitet, sind es gerade
mal 20.000 Datensätze (also nur 1/6 der
Datensätze der größeren
Problem-Tabelle) und es sind nicht mal
ntext-Felder in dieser Tabelle vorhanden.
Tabelle, war das Ergebnis fast 120.000
Datensätze (in der Tabelle ist in
ettlichen Feldern NULL zugelassen und auch
einige ntext-Felder sind enthalten), bei ner
anderen (kleineren) Tabelle, die derzeit die
gleichen Probleme bereitet, sind es gerade
mal 20.000 Datensätze (also nur 1/6 der
Datensätze der größeren
Problem-Tabelle) und es sind nicht mal
ntext-Felder in dieser Tabelle vorhanden.
Hierzu hab ich noch ne Korrektur, denn ich hatte mir die kleinere Tabelle nicht selbst angeschaut, sondern ein Kollege hatte mir von dem Problem berichtet und er hatte gesagt, die kleine Tabelle hätte keine ntext-Felder, nun ist ihm aber aufgefallen, dass dort doch ein ntext-Feld enthalten ist.
Hat jemand ne Ahnung, wie mit den ntext-Feldern auf der Festplatte verfahren wird?
Ich gehe davon aus, dass die ntext-Felder irgendwie anders behandelt werden, als die übrigen Felder, denn der Enterprise Manager kann den Inhalt der Felder ja auch nur dann anzeigen, wenn der Inhalt sehr kurz ist.
Ich bin wie gesagt in der Administration vom SQL-Server noch nicht wirklich tief drin und hab mich damit bisher auch noch nicht großartig beschäftigen müssen, da der bis auf dann, wenn die Platte mal wieder voll war, bisher Problemlos lief und so extreme Probleme wie zur Zeit hatten wir definitiv noch nie.
Vielen Dank und liebe Grüßle
Saskia
Moin Saskia,
so bleibt es ein Stochern im Nebel.
Wenn Du es vor Deiner Firma verantworten kannst (vor Deiner Firma wegen interner Datenstrukturen) , dann poste mal dieses Mini-DB-Modell als JPEG, veröffentliche hier die paar Zeilen DDL-Skripte, die zum Anlegen von Tablespaces, Tabellen, Views und Indices vorhanden sind und gegebenfalls die Constraints und Trigger, die noch dranhängen.
Wenn Du dann noch ein paar Hausnummern nennen kannst zum Füllungsgrad der Tabelle (vorgehaltene RowLen/reale Zeichen per Datensatz), Änderungsfrequenz der Daten und monatliche Wachstumsrate der tabellen in Prozent, dann können wir hier ernsthaft über Sinnhaftigkeit oder Feintunig diskutieren.
Alternative habe ich oben gepostet: dann lade Dir einen Datenbank-Praktiker aus der Nähe zu Kaffee und Kuchen ein.
Theoretiker und 1200-Seiten-Bücher nützen Dir wenig, es geht ja nicht um eine abstrakte, sondern um Deine konkrete Datenbank.
P.S. Wegen der akuten Probleme: schau doch mal nebenbei, ob eventuell Deine DB-Logdateien inzwischen 2 GByte groß sind...
Grüße
Biber
so bleibt es ein Stochern im Nebel.
Wenn Du es vor Deiner Firma verantworten kannst (vor Deiner Firma wegen interner Datenstrukturen) , dann poste mal dieses Mini-DB-Modell als JPEG, veröffentliche hier die paar Zeilen DDL-Skripte, die zum Anlegen von Tablespaces, Tabellen, Views und Indices vorhanden sind und gegebenfalls die Constraints und Trigger, die noch dranhängen.
Wenn Du dann noch ein paar Hausnummern nennen kannst zum Füllungsgrad der Tabelle (vorgehaltene RowLen/reale Zeichen per Datensatz), Änderungsfrequenz der Daten und monatliche Wachstumsrate der tabellen in Prozent, dann können wir hier ernsthaft über Sinnhaftigkeit oder Feintunig diskutieren.
Alternative habe ich oben gepostet: dann lade Dir einen Datenbank-Praktiker aus der Nähe zu Kaffee und Kuchen ein.
Theoretiker und 1200-Seiten-Bücher nützen Dir wenig, es geht ja nicht um eine abstrakte, sondern um Deine konkrete Datenbank.
P.S. Wegen der akuten Probleme: schau doch mal nebenbei, ob eventuell Deine DB-Logdateien inzwischen 2 GByte groß sind...
Grüße
Biber
