Lade...
 

ObjectStore Server Administration

ObjectStore Server Administration

 

ObjectStore Server starten

ObjectStore ab 7.0

Nr. Schritt Befehl Rückmeldung
1. Dienst starten net start "ObjectStore Server R7.0"  

ObjectStore Server beenden

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.

Anpassen der Server-Parameter

Für die meisten Parameter des ObjectStore® Servers ist der vorgegebene Standardwert richtig. Andere können die Performance deutlich beeinflussen.
Hier finden Sie eine Übersicht und Empfehlungen für die Parameter des ObjectStore Servers.

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.

Eine Übersicht wichtiger Server Parametern und Hinweise zur optimalen Einstellung finden Sie hier.

Prüfen der Datenbank auf Integrität

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 unter 32Bit und 0x5000000000 unter 64Bit).

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

Das Prüfen der Datenbank auf Integrität sollte unbedingt nach einem Absturz des Datenbankservers erfolgen. Der Dienst osverifydb sollte gestartet werden, nachdem der Server und der ObjectStore Dienst wieder hochgefahren worden ist, so dass das transaction-logfile abgearbeitet werden konnte. Gegebenfalls ist nach dem Hochfahren eine Kopie der Datenbank zu erzeugen und osverifydb über diese laufen zu lassen, um den Betrieb so früh wie möglich wieder aufnehmen zu können.

Entfernen gelöschter Objekte

Objekte werden im Betrieb lediglich "logisch" gelöscht. Das heißt, dass diese als gelöscht markiert werden. Um sie wirklich aus der Datenbank zu löschen, ist ein Vorgehen notwendig, wie hier beschrieben.

Backup, Kopie einer Datenbank erstellen

Datenbanken können online (d.h. ohne Unterbrechung des Zugangs) oder offline gesichert werden. Zusätzlich ist zu unterscheiden, ob die gesicherte Datenbank alleine in einem konsistenten Zustand ist, oder ob das ObjectStore-Transaktionslog mitgesichert und im Notfall wieder mit hergestellt werden muss.

Offline-Sicherung

Während der Offline-Sicherung ist kein Zugriff auf die Datenbank möglich. Das Datenbank-Transaktionslog muss nicht mit gesichert werden wenn die Datenbank offline geschaltet wird.

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    
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.

Online-Sicherung

Um eine Datenbank ohne Unterbrechung des Zugangs zu sichern gibt es drei Möglichkeiten:

Snapshots

ObjectStore unterstützt die Sicherung der Datenbank über Snapshots des Filesystems, unter der Voraussetzung, dass die Snapshots über Kommandozeile erzeugt werden können. Das gilt bspw. für Microsoft VSS (Windows Shadow-Copy in NTFS) oder NetApp. Es muss sichergestellt sein, dass die Datenbank und das Transaktionslog vollständig und konsistent im Snapshot enthalten sind. Das kann realisiert werden, indem entweder der ObjectStore-Server beendet wird, oder indem der ObjectStore Server in den "quiet mode" umgeschaltet wird. 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 (d.h. die Zeit, in der der Snapshot erstellt werden muss) ist per Default 180 Sekunden und kann mit der Umgebungsvariable OS_QUIET_MODE_TIMEOUT_SECONDS verändert werden.

Der folgende Code kann genutzt werden, um mit Windows VSS einen konsistenten Snapshot zu erzeugen. Das Skript muss auf dem Datenbank-Server ausgeführt werden. Im Beispiel wird angenommen, dass das Datenbank-Transaktionslog irgendwo auf Laufwerk c: und die Datenbank irgendwo auf Laufwerk d: liegt:

ossvrquiet localhost "vssadmin create shadow /for=c:;vssadmin create shadow /for=d:"

Nach dem Aufruf kann mit NTFS-Mitteln (z.B. Windows Explorer oder Backup-Tools von Drittanbietern) auf vorherige Versionen und damit Backups der Datenbank und des Transaktionslogs zugegriffen werden.

Obiger Befehl funktioniert für ObjectStore 32-Bit auf einem Windows 64-Bit-System nicht. Es kommt eine Fehlermeldung wie:

"Fehler: Unerwarteter Fehler: Klasse nicht registriert"

Das liegt an der "Sandbox", in der 32-Bit Anwendungen unter Windows 64-Bit laufen (Stichwort WoW64). Über folgenden Umweg kann der Befehl allerdings auch für ObjectStore 32-Bit verwendet werden:

ossvrquiet localhost "%systemroot%\sysnative\cmd.exe /c vssadmin create shadow /for=c:;%systemroot%\sysnative\cmd.exe /c vssadmin create shadow /for=d:"

 

Um das erzeugte Backup wieder herzustellen müssen die ObjectStore Server Dienste beendet werden und danach das Transaktionlog und das Datenbankbackup an die ursprünglichen Orte kopiert werden. Nun aktiviert man wieder die Dienste, dabei werden die Daten aus dem Transaktionslog in die Datenbank geschrieben und diese lässt sich wieder aufrufen.

osbackup

Ein online-Backup-Tool von ObjectStore sind die osbackup und osarchive. Die Datenbank kann in dem Zeitraum weiter benutzt werden, aber das Backup dauert dann länger. Bitte konsultieren Sie die Dokumentation von ObjectStore®, wenn Sie osbackup/osarchive benutzen wollen. In Zweifelsfällen wenden Sie sich bitte direkt an den ClassiX®-Support.
Anmerkung: osbackup erzeugt keine direkte Datenbankkopie, sondern die Datenbank wird in einem eigenen Format abgelegt, das bei Bedarf mit osrestore wieder eingespielt werden muss. Mit osarchive werden Transaktionen einzeln auf dem Backup nachgefahren, so dass u.U. minütliche Stände zurückgefahren werden können.

oscopy

Eine weitere einfache Möglichkeit, eine Datenbankkopie ohne Abschalten des Servers zu erhalten, ist oscopy:

oscopy server-Datenbankpfad Ziel-Datenbankpfad

Allerdings nimmt oscopy sehr viele Ressourcen in Anspruch, so dass ein Weiterarbeiten während des Kopierens stark beeinträchtigt wird. oscopy ist daher nur für kleine Datenbanken geeignet oder während nicht viel auf dem Server gearbeitet wird. Der Vorteil besteht darin, dass die Zieldatei sofort als Datenbank zur Verfügung steht. Achtung: Die Datenbank ist keine 1:1-Kopie. Während des Kopierens werden leere Bereiche der Datenbank physisch gelöscht und defragmentiert,

Packen von Datenbanken ab 5GB

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.

 

Vorgehensweise oscopy-Lauf

Ziel

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.

Benutzte Hilfsmittel

  • Startmöglichkeiten für ClassiX-Umgebung (Version 4.5.xxx) auf 2 Datenbanken – Original, und Kopie (hier mit Platzhaltern dborig und dboscopy bezeichnet), die im Verlauf des Vorgehens angelegt wird
  • Ein Win-32-bit-Rechner mit ObjectStore 32-bit

 

Ausführung

  • Login auf ClassiX-Datenbank unterbinden, alle Benutzer ausloggen
  • Offline schalten
    osdbcontrol -offline dbname
  • Mit normalen Windows-Mitteln eine Kopie für Backupzwecke anlegen
  • Online schalten
  • Oscopy anwenden
    oscopy dborig dboscopy
    Anmerkung: oscopy lastet ObjectStore aus, ein paralleler Zugriff auf andere Datenbanken dieses Rechners dauert dann erheblich länger, daher sollte für die Zeit des oscopy nichts anderes laufen
  • Testweise ClassiX-Umgebung auf dboscopy starten
  • Beide Datenbanken offline schalten
  • dboscopy nach dborig kopieren
  • Die neue dborig wieder online schalten
  • Login wieder erlauben

 

Backup-Script

Backup-Script
@echo off
SET SOURCE_DB=Pfad zur Datenbank einschließlich Datenbank.
SET TARGET_DB=Pfad und Datenbankname in die SOURCE_DB gesichert werden soll.
SET TEST_DB=Pfad und Name der Testdatenbank
SET SERVER_NAME=Namen des Servers

REM Checkpoint erstellen
ossvrchkpt %SERVER_NAME%

REM Echtdatenbank Alle clients trennen und offline schalten
osdbcontrol -offline -kill_clients %SOURCE_DB%

REM Echtdatenbank ins DB-Backup-Verzeichnis kopieren (sollte bereits eine DB mit dem selben Namen vorhanden sein, wird diese überschrieben.)
COPY /Y %SOURCE_DB% %TARGET_DB%
REM Backup der Echtdatenbank als Test-Datenbank kopieren (vorhandene Test-Datenbank wird überschrieben)
COPY /Y %TARGET_DB% %TEST_DB%

REM Echt- und Test-Datenbank wieder online schalten
osdbcontrol -online %SOURCE_DB%
osdbcontrol -online %TEST_DB%

 

Server Neustart

Achtung: Nicht der ObjectStore-Server soll neugestartet werden, sondern der Windows-Server.

Es ist beobachtet worden, dass bei Servern mit hoher Laufzeit die ObjectStore Operationen länger benötigen als nach Serverstart.

Um dies vorzubeugen, sollte man einen Server-Neustart mindestens einmal im Monat einplanen. 

In Umgebungen, in denen ein hoher Zugriff auf die ObjectStore-Datenbanken vorhanden ist (viele gleichzeitige User oder sehr viele kleine Zugriffe) kann es sich Lohnen den Neustart-Intervall auf bis zu einmal pro Woche zu erhöhen.

InstantView