| Nr. | Schritt | Befehl | Rückmeldung |
|---|---|---|---|
| 1. | Dienst starten | net start "ObjectStore Server R6.0" |
| Nr. | Schritt | Befehl | Rückmeldung |
|---|---|---|---|
| 1. | Dienst starten | net start "ObjectStore Server R7.0" |
| Nr. | Schritt | Befehl | Rückmeldung |
|---|---|---|---|
| 1. | Überprüfen, ob Clients am Server aktiv sind | ossvrstat -clients SERVER* | "no active clients" oder eine Liste der mit dem Server verbundenen Clients |
| 2. | Sicherstellen, dass kein Client mit dem Server verbunden ist | perl killclients.pl SERVER* | ERRORLEVEL = 0: kein Client mehr verbunden, sonst: es sind noch Clients mit dem Server verbunden |
| 3. | Checkpoint erstellen | ossvrchkpt SERVER* | ERRORLEVEL = 0: alles ok; Programm beendet sich erst dann, wenn der Checkpoint vollständig ist |
| 4. | Datenbank(en) offline schalten | osdbcontrol -offline -kill_clients DATENBANK* | |
| 5. | ObjectStore® Server herunterfahren | ossvrshtd -f SERVER* | |
| 6. | Etwas warten | ||
| 7. | ObjectStore® Server-Checkpoint nochmal durchführen | osserver -c -con (Aufruf ohne OS-Server) |
LOG 0001
There are no partitions specified in the parameters file. Only file databases will be accessible through this server. |
| 8. | Sich vergewissern, dass in ObjectStore® Server-Protokolldatei keine Abbruch-Meldung oder sonst etwas auffälliges steht | Datei osserver.txt in %OS_TMPDIR%- oder %TEMP%-Verzeichnis | |
| * SERVER ist der Name des Datenbankservers, DATENBANK der Name der Datenbank, wie er auf der Platte gespeichert ist | |||
Der ObjectStore® Server muss nur dann beendet werden, wenn die Maschine heruntergefahren werden soll. Für Backupzwecke ist es völlig ausreichend, die Datenbank offline zu schalten.
Für die meisten Parameter des ObjectStore®
Servers ist der vorgegebene
Standardwert richtig. Andere können die Performance deutlich
beeinflussen. Diese Parameter sollten bei Performanceproblemen überprüft
werden. Dabei ist auf die jeweiligen Eigenschaften und Gegebenheiten der
konkreten Netzwerk-, Hardware- und Softwareinstallation zu achten.
Die Zielstellung ist, das Verhalten des Servers bei
folgenden Aktionen zu steuern:
Die aktuell eingestellten Server Parameter können mit dem Befehl: ossvrstat -parameters hostname abgefragt werden (für hostname ist der Name des Servers einzutragen).
Achtung!
Nach Veränderung der Parameter muss der ObjectStore® Server
neu gestartet werden, damit die Änderungen auch wirksam werden.
| Parameter | Standardwert | Empfohlener Wert | Erläuterung |
|---|---|---|---|
| Cache Manager Ping Time In Transaction | 300 | 60 | Um überflüssige Locks nach unerwartetem Beenden eines ClassiX® Clients zu vermeiden, sollte dieser Wert verringert werden. Der Server prüft dann häufiger nach, ob ein Client noch erreichbar ist. |
| Max AIO Threads | 3 | 32 | Der vorgegebene Standard-Wert ist zu klein, Threads werden ständig
neu gestartet! Die genaue Anzahl an Threads hängt auch auch von der Anzahl gleichzeitig verwendeter Datenbanken ab. |
| Max Data Propagation Per Propagate | Auto (0) | 3328 | Dieser Wert kann verringert werden, um ein häufigeres Schreiben in die Datenbank zu erzwingen. Standardmäßig hängt dieser Wert von "Propagation Buffer Size" (s.u.) ab, d.h. in der Regel sollte Propagation Buffer Size verkleinert werden. |
| Message Buffer Size | 512 | 32768 | Um die Kommunikation zwischen dem Server und den Clients zu beschleunigen, kann dieser Wert erhöht werden. |
| N Message Buffers | 4 | 128 | Um dem Server die parallele Kommunikation mit mehreren Clients zu erlauben, kann dieser Wert entsprechend der maximal zu erwartenden Anzahl an Clients erhöht werden. Die Notwendigkeit hierzu kann durch den Aufruf von "ossvrstat -meters serverhostname" erkannt werden. Wenn in den Feldern "message buffer waits" Werte größer 0 vorkommen, dann kann die Performance durch die Erhöhung dieses Wertes u.U. verbessert werden. |
| Preferred Network Receive Buffer Size | 16384 | 65536 | Der Wert der Umgebungsvariablen OS_RCVBUF_SIZE
in der aufrufenden Batch Datei sollte den gleichen Wert haben |
| Preferred Network Send Buffer Size | 16384 | 65536 | Der Wert der Umgebungsvariablen OS_SNDBUF_SIZE
in der aufrufenden Batch Datei sollte den gleichen Wert haben |
| Propagation Buffer Size | Auto | 327680 | Dieser Wert kann verringert werden, um ein häufigeres Schreiben in die Datenbank zu erzwingen (steht auch im Zusammenhang mit "Max Data Propagation Threshold"). |
Weiter Hinweise zu Server Parametern und Methoden für eine Kontrolle finden sie hier.
| Nr. | Schritt | Befehl | Kommentar |
|---|---|---|---|
| 1. | Datenbank prüfen (ObjectStore utility) | osverifydb -F -limit 999999 DATENBANK* > ergebnis.dat 2>>&1 | Das Ergebnis der Prüfung wird in die Datei ergebnis.dat
geschrieben. Meldungen wie „internal error“ oder „err_“ bitte sofort bei ClassiX® melden ! osverifydb hat zwei Modi, die dasselbe Ergebnis liefern, aber unterschiedlich schnell. Mit -F wird der schnellere ausgewählt. Ohne Parameter stoppt osverifydb bei einer bestimmten Anzahl von Fehlern. Mit -limit 999999 wird angegeben, dass bis zu 999999 Fehler angezeigt werden sollen. Weitere Informationen können Sie mit osverifydb /? oder in der ObjectStore-Dokumentation bekommen. Sollten Addressspace-bezogene Fehler auftreten empfiehlt es sich, vor dem Aufruf die Umgebungsvariable OS_AS_SIZE auf einen entsprechend hohen Wert zu setzen (z.B. 0x45000000). Um große Datenbanken schneller analysieren zu können, lässt sich die Aanalyse auf die Segmente parallelisieren. Ein Powershell-Skript finden Sie unten. |
| 2. | Ergebnis prüfen | Die Analyse wird in zwei Phasen durchgeführt. In der ersten
werden die Pointer analysiert, in der zweiten die Collections. Die Ausgabe
enthält neben den Fehlern eine Menge Status-Informationen und Warnungen. Die
Fehler der ersten Phase starten alle mit "The object at", die der zweiten
Phase mit "The collection at". Einige Fehler sind bekannt bzw. lediglich Warnungen. Diese können mit einem Skript gefiltert werden. |
|
| * DATENBANK ist der Name der Datenbank wie er auf der Platte gespeichert ist | |||
| Skripte | |||
| Nr. | Schritt | Befehl | Anmerkung |
|---|---|---|---|
| 1. | Sicherstellen, dass kein Client mit dem Server verbunden ist | perl killclients.pl SERVER* | ERRORLEVEL = 0: kein Client mehr verbunden, sonst: es sind noch Clients mit dem Server verbunden |
| 2. | Checkpoint erstellen | ossvrchkpt SERVER* | ERRORLEVEL = 0: alles ok; Programm beendet sich erst dann, wenn der Checkpoint vollständig ist |
| 3. | Datenbank offline schalten | osdbcontrol -offline -kill_clients DATENBANK* | |
| 4. | Datenbankdatei mit üblichen Backupmitteln sichern | Läuft der ObjectStore Server im quiet mode wird empfohlen, immer auch eine Kopie des Server Transaktions-Logfiles (osserver.log) zu erstellen. | |
| 5. | Datenbank online schalten | osdbcontrol -online DATENBANK* | |
| * SERVER ist der Name des Datenbankservers, DATENBANK der Name der Datenbank, wie er auf der Platte gespeichert ist | |||
Es ist nicht notwendig, den ObjectStore® Server zu beenden.
Alternativ kann auch osbackup von ObjectStore® benutzt werden. Die Datenbank
kann in dem Zeitraum weiter benutzt werden, aber das Backup dauert hier länger
(ca. 4GB/Stunde bei ObjectStore 6.0, ca. 9 GB/Stunde bei ObjectStore® 6.2). Bitte
konsultieren Sie die Dokumentation von ObjectStore®, wenn Sie osbackup benutzt
wollen. In Zweifelsfällen wenden Sie sich direkt an ClassiX®.
Anmerkung: osbackup erzeugt keine direkte Datenbankkopie, sondern die
Datenbank wird in einem eigenen Format abgelegt, das bei Bedarf mit osrestore
wieder eingespielt werden muss.
Eine weitere Möglichkeit, eine Datenbankkopie ohne Abschalten des Servers zu erhalten, ist oscopy
mit den Argumenten Ursprungsdatenbank und Zieldatei. Allerdings nimmt
oscopy sehr viele Ressourcen in Anspruch, so dass ein Weiterarbeiten
während des Kopierens stark beeinträchtigt wird.
Auch kann die Snapshot-Funktion eines NetApp-SAN genutzt werden. Entweder fährt man
hierzu den ObjectStore-Server-Dienst für die Dauer des Backupvorgangs herunter, oder der
ObjectStore Server ist in den "quiet mode" umzuschalten. Das Werkzeug
hierzu ist ossvrquiet. Dabei muss ein ObjectStore-Server und eine
ausführbare oder Batch-Datei mit den Backup-Kommandos angegeben werden.
Die maximale Zeit im Quiet-Modus ist per Default 180 Sekunden und kann mit
der Umgebungsvariable OS_QUIET_MODE_TIMEOUT_SECONDS verändert werden.
(Getestet ist: NetApp
FAS3050 running on the Data ONTAP Version 7.2.1.1 operating system in an NFS
Version 3, or NFS Version 4, or CIFS environment)
osarchiv muss nicht zwingend benutzt werden: There is no need to use it unless you want to keep a log of all transactions between backups that can be used by osrecovr in order to "roll forward" a specific, previously recorded, state of the databases.
Hier noch ein paar Hinweise zum Beenden von osarchiv:
By default, osarchiv runs in the foreground
and there is no option/command to stop it. If a kill signal is received while
osarchiv is active (versus in the wait state), the archive will be truncated and
thus unusable. Therefore, one or more of the following options can be used:
1) Use -C (capital C) option to enable the interactive command-loop feature.
Use of this feature allows changes to the osarchiv parameters while the utility
is still running. Once -C is enabled, add/append a -q to the parameters file to
stop the archive process.
2) Use -c (lowercase c) option to provide a clean-up handler. Use of this
feature allows a Control-C to exit the utility.
Ist die Datenbank für die üblichen Zip Programme für Windows zu groß, dann
kann sie stellvertretend mit GZip oder 7-zip gepackt werden.
Es wurde ein Setup erstellt, welches die Datenbanken bei Doppelklick mit GZip
packt. Das Setup ist hier zu finden.
Das Kopieren der Datenbank mit oscopy führt neben dem Kopieren eine interne Reorganisation durch. Bei einer lange nicht reorganisierten Datenbank verringern sich die Zugriffszeiten deutlich bei einer geringfügigen Zunahme der Datenbankgröße. Voraussetzung für die Durchführung durch den Kunden selbst ist eine fehlerfreie Datenbank.