Original von Brad M. McGehee; deutsche Übersetzung von Frank Kalis
Falls Sie SQL Server 2000 Standard Edition unter Windows NT 4.0 oder Windows 2000 (alle Versionen) oder SQL Server 2000 Enterprise Edition unter Windows NT 4.0 oder Windows 2000 Server betreiben oder Ihr Server 4 GB RAM oder weniger RAM hat, sollte die "awe enabled" Option auf ihrem Standardwert von 0 belassen werden. Dies bedeutet, dass AWE nicht verwendet wird.
Das AWE (Advanced Windowing Extensions) API ermöglicht Applikationen (die dafür geschrieben wurden) unter Windows 2000 Advanced Server oder Windows 2000 Datacenter Edition mehr als 4 GB RAM zu adressieren. SQL Server 2000 Enterprise Edition (nicht die Standard Edition) ist AWE-fähig und kann damit mehr als 4 GB RAM eines Servers nutzen. Ist das Betriebssystem Windows 2000 Advanced Server, kann SQL Server 2000 Enterprise Edition bis zu 8 GB RAM adressieren. Ist das Betriebssystem Windows 2000 Datacenter Edition kann SQL Server 2000 Enterprise Edition bis zu 64 GB RAM verwenden.
Standardeinstellung jedoch ist, dass SQL Server 2000 Enterprise Edition unter Windows 2000 (Advanced oder Datacenter) auf einem physikalischen Server nicht mehr als 4 GB RAM ansprechen kann; auch wenn der Server über mehr RAM verfügt. Damit das Betriebssytem und SQL Server 2000 Enterprise Edition nun dieses zusätzliche RAM adressieren können, müssen zwei Schritte ausgeführt werden.
Wie Sie genau die AWE Memory Unterstützung konfigurieren, hängt davon ab, wieviel RAM ihr Server hat. Um Windows 2000 (Advanced oder Datacenter) zu konfigurieren, müssen Sie einen der folgenden beiden Schalter in die Boot Zeile der boot.ini Datei eingeben und den Server neu starten.
Der /3GB Schalter wird benutzt, um mitzuteilen, dass SQL Server 3 der 4 GB Basis RAM verwenden kann, die Windows 2000 nativ unterstützt. Geben Sie diese Option nicht an, nutzt SQL Server nur 2 GB der ersten 4 GB RAM des Servers, essentiell wird damit 1 GB RAM verschwendet.
AWE Memory Technologie wird nur für den Teil des RAM benutzt, der die Basis von 4 GB RAM überschreitet. Aus diesem Grund wird der /3GB Schalter verwendet, damit Sie soviel RAM Ihres Servers wie möglich verwenden können. Hat Ihr Server weniger als 16 GB RAM ist es wichtig, den /3GB Schalter zu benutzen. Hat Ihr Server hingegen mehr als 16 GB RAM, müssen Sie diesen Schalter nicht angeben. Der Grund hierfür ist, dass das Betriebssystem den 1 GB zusätzlichen RAM, der durch den /3GB Schalter bereitgestellt wird, benötigt, um das komplette zusätzliche AWE Memory zu managen, falls Ihr Server über mehr als 16 GB RAM verfügt.
Sind 16 GB oder weniger in einem Server, braucht das Betriebssystem nur 1 GB RAM, so dass SQL Server das andere GB RAM verwenden kann.
Ist dieser Schritt ausgeführt, ist der nächste Schritt, die "awe enabled" Option in SQL Server 2000 Enterprise Edition auf 1 zu setzen und anschliessend den SQL Server Dienst neu zu starten. Nur dadurch ist SQL Server in der Lage, das zusätzliche RAM zu verwenden.
Ein Hinweis zur Verwendung der "awe enabled" Einstellung. Nachdem diese eingeschaltet ist, managt SQL Server nicht mehr dynamisch den Arbeitsspeicher. Stattdessen verwendet SQL Server sämtlichen verfügbaren RAM (bis auf ca. 128 MB, das für das Betriebssystem übrig gelassen wird). Wollen Sie verhindern, dass SQL Server sämtliches RAM für sich beansprucht, müssen Sie die "max server memory" (wird weiter unten ausführlich beschrieben) auf den Wert setzen, den Sie SQL Server zugestehen wollen (7.0, 2000) Aktualisiert 02.01.2004
Für den Fall, dass Sie das Gefühl haben, dass Ihr Arbeitsspeicher zum Flaschenhals wird, und unter der Voraussetzung, dass Sie Geld zum Ausgeben haben; SQL Server 2000 Enterprise Edition kann bis zu 64 GB RAM unterstützen. Wieviel Speicher tatsächlich genutzt werden kann, hängt ab von Ihrer Windows 2000 oder Windows 2003 Version und davon, wieviel RAM Ihr Server unterstützt. Ist Ihr Server dafür ausgelegt, unterstützt SQL Server 2000 Enterprise Edition bis zu 8 GB unter Windows Advanced Server und bis zu 64 GB unter Windows Datacenter.
32-bit CPU's wie die Pentium Prozessorenfamilie unterstützen aufgrund ihres limitierten Adressraumes normalerweise nur bis zu 4 GB RAM. Un nun diese Begrenzung zu umgehen, unterstützt SQL Server 2000 Enterprise Edition ein Feature namens AWE (Advanced Windowing Extensions), das bis zu 64 GB RAM adressieren kann.
Angenommen, Sie konfigurieren die entsprechende Hard- und Software, so ist AWE Support nicht automatisch eingeschaltet. Sie müssen die 'awe enabled' erweiterte SQL Server 2000 Option von 0 auf 1 setzen, um die AWE Unterstützung zu aktivieren. Zum Beispiel. folgendermassen:
SP_CONFIGURE 'show advanced options', 1
RECONFIGURE
GO
SP_CONFIGURE 'awe enabled', 1
RECONFIGURE
GO
AWE Memory kann nicht dynamisch verwaltet werden, so wie SQL Server normalerweise Speicher managt. Konkret heisst das, dass SQL Server beim Start automatisch sämtlichen Speicher beansprucht, der vorhanden ist (bis auf ca. 128 MB, die für das Betriebssystem reserviert sind). Dieser Speicher wird auch nicht eher freigegeben, bis SQL Server beendet wird. Ist Ihr Server ein dedizierter SQL Server ist dies wahrscheinlich auch in Ordnung. Läuft hingegen noch andere Software auf dem Server oder mehrere Instanzen von SQL Server, dann müssen Sie die maximale Menge RAM angeben, die SQL Server beanspruchen kann, wenn er startet. Dies wird die 'max server memory' Konfigurationsoption erreicht. Ändern Sie diese Einstellung müssen Sie den msssqlserver Dienst neu starten, damit die Änderung wirksam wird.
Um die maximale Menge an Speicher anzugeben, auf die AWE Memory Zugriff hat, benutzen sie SQL Server's 'max server memory' Konfigurationsoption wie folgt:
SP_CONFIGURE 'max server memory', 4096
RECONFIGURE
GO
Mit obigem Beispiel teilen wir SQL Server mit, nur 4 GB RAM zu verwenden und alles restliche verfügbare RAM im Server für andere Applikationen frei zu lassen.
Obwohl mehrere Instanzen von SQL Server mit AWE Memory betrieben werden können, ist dies nicht unbedingt erstrebenswert, da das Management Kopfschmerzen bereiten kann. Tatsächlich steht das Betreiben mehrerer Instanzen von SQL Server in AWE Memory dem Sinn von mehr RAM entgegen. Generell sollte Ihr Ziel beim Gebrauch von AWE Memory sein, eine einzelne sehr grosse Instanz von SQL Server zu unterstützen, nicht viele kleinere Instanzen auf einem einzelnen Server.
Angenommen, Sie verfügen über das Budget, kann das Hinzufügen grosser Mengen RAM viele Datenbanken deutlich beschleunigen (7.0, 2000) Aktualisiert 02.01.2004.
Microsoft betrachtet AWE Memory als Premium Feature; deshalb wird es nicht in allen Versionen von Windows 2000 und SQL Server 2000 angeboten. Es folgt eine Tabelle der verschiedenen Versionen von Windows 2000 und SQL Server 2000, die zeigt, ob und wieviel AWE Memory unterstützt wird.
Windows |
SQL 2000 |
SQL 2000 |
SQL 2000 |
SQL 2000 |
Windows 2000 |
64 GB |
2 GB |
2 GB |
64 GB |
Windows 2000 |
8 GB |
2 GB |
2 GB |
8 GB |
Windows 2000 |
4 GB |
2 GB |
2 GB |
4 GB |
Windows 2000 |
N.A. |
N.A. |
2 GB |
2 GB |
Jede der obigen Kombinationen über 4 GB wird durch AWE Memory unterstützt. Wollen Sie AWE Memory einsetzen, haben Sie keine andere Wahl, als Microsoft's Premium-teure Produkte zu kaufen.
Wenn Sie AWE Memory einsetzen, können Sie die Performance durch einige spezielle Performance Monitor Counter verfolgen, die Sie unter dem Server Buffer Manager Objekt finden. diese schliessen ein:
(7.0, 2000) Aktualisiert 02.01.2004.
Den Originalartikel finden Sie hier
DELETE logged die Daten für jede einzelne Zeile, die von dem Statement betroffen sind und entfernt physikalisch den Record aus der Seite. Fährt man seine Datenbanken im "Full Recovery" Modus, kann die Aufzeichnung eines jeden einzelnen betroffenen Datensatzes das Transaktionsprotokoll enorm aufblähen. Dies ist aber notwendig, damit SQL Server im Falle einen Falles die Datenbank so aktuell wie möglich wiederherstellen kann. Der Umstand, das jeder Datensatz protokolliert wird, macht auch verständlich, daß umfangreiche DELETE Operationen langsam sind.
Nicht wirklich. Da bei einem INNER JOIN nur die Werte beider Tabellen gefunden werden, bei denen die Spaltenwerte die per JOIN verknüpft werden, identisch sind, gilt folgendes:
A=B
was logischerweise auch bedeutet:
B=A
Von daher ist die Tabellenanordnung irrelevant. Intern wird der Query Optimizer von sich aus eine Entscheidung treffen, in welcher Reihenfolge auf die Tabellen am effektivsten zugegriffen werden kann.
Generell gilt, daß Indexes Datenabfragen enorm beschleunigen können. Nachteil aber ist, daß Änderungen an den Daten sich auch in Änderungen in den Indexes manifestieren, falls die entsprechenden Spalten, die von der Änderung betroffen sind, auch gleichzeitig Teil eines oder mehrerer Indexes sind. Indexes aber sind kein starres Konzept, von dem man nicht abweichen darf. So macht es zum Beispiel durchaus Sinn, vor dem Auffüllen einer Tabelle durch einen Massenimport, vorhandene Indexes auf der Tabelle zu löschen, um den Import zu beschleunigen und vielleicht innerhalb eines vorgegebenen Zeitfensters beenden zu können. Die Frage, ob in einem solchen Fall nicht besser die gesamte Tabelle gelöscht und neu erstellt wird, ignorieren wir an dieser Stelle. Sie ist ein eigenes Thema und nicht Gegenstand dieser Betrachtung.
In SQL 6.5 gibt es eine Einstellungen 'tempdb in RAM'. Ab Version 7 wird dies nicht mehr unterstützt. Microsoft ist der Ansicht, daß die internen Zugriffe genügend optimiert sind, um dies unnötig zu machen