Führt den Datenbankserver im Speicher aus und reduziert oder eliminiert damit Schreibvorgänge auf der Festplatte.
{ dbsrv11 | dbeng11 } -im { c | nw } ...Alle Betriebssysteme und Datenbankserver.
Für den speicherresidenten Modus benötigen Sie eine separate Lizenz. Weitere Hinweise finden Sie unter Getrennt lizenzierbare Komponenten.
Diese Funktion ist besonders sinnvoll auf Systemen mit großem Arbeitsspeicher, der alle Datenbankdateien im Cache verfügbar halten kann. Zwei speicherresidente Modi sind verfügbar:
Nur Checkpoint (-im c) Im Modus "Nur-Checkpoint" verwendet der Datenbankserver kein Transaktionslog und Sie können die letzte festgeschriebene Transaktion nicht wiederherstellen. Da jedoch das Checkpoint-Log aktiviert ist, kann die Datenbank bis zum letzten Checkpoint wiederhergestellt werden. Wenn Sie eine Datenbank ohne Transaktionslog betreiben, setzt der Datenbankserver beim Festschreiben dennoch einen Checkpoint, worunter die Performance leidet. Wenn Sie hingegen den Datenbankserver im Nur-Checkpoint-Modus betreiben, setzt der Datenbankserver nicht nach jedem Festschreiben einen Checkpoint.
Dieser Modus ist bei Anwendungen sinnvoll, die eine höhere Performance benötigen, und bei denen ein Verlust von festgeschriebenen Transaktionen nach dem letzten Checkpoint akzeptiert werden kann.
Die folgenden Einschränkungen gelten, wenn der Datenbankserver im Nur-Checkpoint-Modus läuft:
Es gibt kein Transaktionslog.
Es gibt keine temporäre Datei.
Checkpoints sind auf Verlangen und im Rhythmus der normalen Checkpoint-Frequenz des Datenbankservers erlaubt.
Dirty Pages werden nur bei einem Checkpoint auf die Festplatte ausgelagert.
Nie Schreiben (-im nw) Im Modus "Nie-Schreiben" werden festgeschriebene Transaktionen nicht in die Datenbankdatei auf dem Plattenspeicher geschrieben. Alle Änderungen gehen verloren, wenn die Datenbank herunterfährt oder abstürzt, die Datenbankdateien bleiben daher immer in ihrem ursprünglichen Zustand. Anforderungen zur Erweiterung bestehender oder Schaffung neuer DBSpaces sind zulässig, aber die Änderungen spiegeln sich in den Datenbankdateien nicht wider. Sie können neue DBSpaces erstellen und verwenden, sie werden aber nicht auf die Festplatte geschrieben. Eine Sicherung im Modus "Nie schreiben" ist nicht sinnvoll, weil Änderungen im System-DBSpace nicht in die Datei geschrieben werden.
Die folgenden Einschränkungen gelten, wenn der Datenbankserver im Nie-Schreiben-Modus läuft:
Es gibt kein Transaktionslog.
Es gibt kein Checkpoint-Log.
Es gibt keine temporäre Datei.
Dirty Pages der Datenbank werden nie auf Festplatte ausgeschrieben.
Die ursprünglichen Datenbankdateien werden nie geändert.
Da Änderungen nie in die ursprünglichen Datenbankdateien geschrieben werden, müssen Sie das Dienstprogramm dbunload oder die Anweisung UNLOAD TABLE verwenden, wenn eine beständige Kopie der aktuellen Datenbankinhalte erforderlich ist. Sie können auch SQL-Abfragen verwenden, um die Änderungen abzufragen, müssen diese Änderungen dann aber manuell in die Datenbankdatei schreiben.
Ob der speicherresidente Modus Performancevorteile bringt, hängt von der Verarbeitungslast der Anwendung und dem Datendurchsatz des I/O-Subsystems ab. Die größten Performancegewinne werden bei Anwendungen erzielt, die große Datenmengen einfügen oder aktualisieren, sowie in Anwendungen, die häufig Festschreibungsvorgänge durchführen und einen Checkpoint setzen.
Oft ist die Performance bei speicherresidenten Modi mindestens so gut wie bei der Verwendung von transaktionalen globalen temporären Tabellen. Die geringsten Performanceverbesserungen werden bei Anwendungen festzustellen sein, die hauptsächlich die Datenbank abfragen. Im Allgemeinen können bei der Verwendung des speicherresidenten Modus die größten Performancevorteile erzielt werden, wenn der Cache von vornherein auf eine Größe erweitert wird, der den gesamten, zu erwartenden Inhalt der Datenbankdateien aufnehmen kann. Damit wird viel Overhead vermieden, der durch die inkrementierte Erhöhung des Caches während der laufenden Anwendung entsteht.
Da die Seiten im Nie-Schreiben-Modus nie aus dem Cache ausgelagert werden, kann der verfügbare Cache aufgebraucht werden, wenn die Menge der Daten in der Datenbank zu groß wird. Wenn dies eintritt, gibt SQL Anywhere eine Fehlermeldung aus und sperrt die Verarbeitung von Anforderungen. Aus diesem Grund sollte der Nie-Schreiben-Modus mit Bedacht verwendet und dafür Sorge getragen werden, dass der Cache so groß bemessen wird, dass die komplette Arbeitskopie der von der Anwendung benutzten Seiten darin Platz hat. Da Checkpoints im Modus "Nur-Checkpoint" weiterhin gesetzt werden, besteht im Vergleich zum Modus "Nie Schreiben" ein geringeres Risiko, dass der Server nicht mehr genügend verfügbaren Cache hat.
Für die Anweisung LOAD TABLE und einige ALTER TABLE-Anweisung wird das Checkpoint-Log verwendet, um die Auswirkungen einer Systemstörung teilweise aufzuheben oder eine Wiederherstellung nach einem Fehler vorzunehmen. Im "never write"-Modus wird kein Checkpoint-Log erstellt und Sie können die Wirkungen bestimmter Anweisungen bei Fehlern nicht teilweise zurücksetzen. Falsche oder unvollständige Daten könnten daher in Tabellen verbleiben. Weitere Hinweise finden Sie unter Hinweise zum Checkpoint-Log.
| Kommentieren Sie diese Seite in DocCommentXchange. Senden Sie uns Feedback über diese Seite via E-Mail. |
Copyright © 2009, iAnywhere Solutions, Inc. - SQL Anywhere 11.0.1 |