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 Analyse 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. Um sicherzustellen, dass die letzten Transaktionen aus dem Log in die Datenbank propagiert wurden, sollte vor ossvrquiet noch ein ossvrchkpt ausgeführt 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:

ossvrchkpt localhost
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:

del "backups\database.cxd" oscopy "database.cxd" "backups\database.cxd" ossvrchkpt localhost

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. Hinweis: Die Datenbank ist keine 1:1-Kopie. Während des Kopierens werden leere Bereiche der Datenbank physisch gelöscht und defragmentiert. 

oscopy arbeitet im MVCC-Modus, was bedeutet, dass ein konsistenter Snapshot der Datenbank kopiert wird. Um dies zu erreichen, werden Änderungen während des oscopy-Befehls nicht aus dem Server-Log in die Datenbank propagiert. Viele Schreibprozesse während eines langen oscopy-Laufs können also zur Folge haben, dass das Server-Log stark anwächst.

Achtung: Bei der Kopie mit oscopy ist unbedingt darauf zu achten, dass im Zielpfad keine Datei existiert. Falls in eine existierende Datenbankdatei per oscopy kopiert wird, dann wird die Kopie zwar korrekt durchgeführt, jedoch wächst hierdurch das Server-Log (osserver.log) auf ein Vielfaches der zu kopierenden Datenbankgröße und die Datenbankdatei selbst wird durch diesen Vorgang größer (wird wieder kleiner, wenn man die Datenbank in einen Pfad ohne Zieldatei kopiert).

Deswegen sollte die Zieldatei vor einem oscopy immer vorher gelöscht werden (z.B per del)

Der ossvrchkpt-Befehl nach der Kopie ist notwendig, um die Änderungen aus dem Serverlog in die Backup-Datenbank zu propagieren für den Fall, dass die Backup-Datenbank offline gesetzt, verschoben oder gezipped werden soll, ansonsten kann es sein, dass man ein unvollständiges Backup sichert.


Recovery, Wiederherstellung der Datenbank

Backup Recovery
Offline-Backup

Die Datenbank kann direkt aus dem Backup kopiert werden.
Die Datenbank muss Online geschaltet werden.

Oscopy Die Datenbank kann direkt aus dem Backup kopiert werden.
Die Datenbank muss Online geschaltet werden.
Shnapshot Die ObjectStore-Dienste müssen beendet werden.
Danach Datenbank und Transaktionslog aus der Datenbank wieder erstellen und an Ihren jeweiligen Platz kopieren. Nun die Dienste wieder aktivieren, damit die Daten aus dem Transaktionlog wieder in der Datenbank geschrieben werden könnne
Osbackup Mit osrestore kann das Backup der Datenbank wieder eingespielt werden.

 

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

Offline-Version

Offline 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%


Online Version

Online Backup-Script mit oscopy
@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 SERVER_NAME=Namen des Servers REM Checkpoint erstellen ossvrchkpt %SERVER_NAME% REM Aus der Echtdatenbank wird eine Online-Kopie im Ziel-Verzeichnis erstellt. oscopy %SOURCE_DB% %TARGET_DB% REM Checkpoint erstellen ossvrchkpt %SERVER_NAME%

 

 

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.

 

Log-Level hochsetzen

Der Server schreibt ein Log, das für Fehlersuche bei Korruptionen hilfreich sein kann. Das Log liegt normalerweise im Installationsvereichnis von ObjectStore unter /temp/osserver.txt. Der Speicherort kann durch das Setzen von %OS_TMPDIR% geändert werden und der Name der Log-Datei lässt sich per %OS_SERVER_OUTPUT_LOG_NAME% konfigurieren. Falls man die Datei nicht finden kann, dann sollten die beiden Umgebungsvariablen geprüft werden und notfalls mit dem ProcessExplorer die offenen Dateihandles vom osserver.exe-Prozess (Admin-Rechte erforderlich) untersuchen.

 

Das Log-Level kann auf Debug gesetzt werden, indem in der Registry  der Eintrag ImagePath vom ObjectStore-Server-Dienst von:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObjectStore Server R2013\ImagePath
C:\ODI_2013.0(U20)_VS2012\OStore\BIN\OSSERVER.EXE

geändert wird in:

Computer\HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ObjectStore Server R2013\ImagePath
C:\ODI_2013.0(U20)_VS2012\OStore\BIN\OSSERVER.EXE -d 1

Anschließend muss der Server-Dienst neu gestartet werden und dann loggt der Server im Debug-Level. Öffnet man in der Dienstverwaltung das Eigenschaftenfenster des ObjectStore-Server-Diensts, dann sollte man den geänderten Pfad unter "Pfad zur EXE-Datei:" sehen können.

Achtung: Hierdurch wächst die Logdatei des Servers deutlich schneller an und sollte in regelmäßigen Abständen gelöscht werden.