ObjectStore Server Administration

ObjectStore Server Administration

• Start ObjectStore® Server
• Exit ObjectStore® Server
• Adjusting the server parameters
• Checking the integrity of the database
• Removing deleted objects
• Backup, create copy of a database
• Recovery, restoring the database
• Packing of databases from 5GB
• Backup script
  • Offline version
  • Online version (oscopy)
• Server restart
• Raise log level

Start ObjectStore Server

ObjectStore from 7.0

Exit ObjectStore Server

The ObjectStore® Server only needs to be stopped when the machine is to be shut down. For backup purposes it is completely sufficient to take the database offline.

Adjusting the server parameters

For most parameters of the ObjectStore® server the default value is correct. Others can influence the performance significantly.
Here you will find an overview and recommendations for the parameters of the ObjectStore Server.

The currently set server parameters can be queried with the command: ossvrstat -parameters hostname (for hostname the name of the server must be entered).

Attention!
After changing the parameters, the ObjectStore® server must be restarted for the changes to take effect.

You can find an overview of important server parameters and tips for optimal settings here.

Checking the integrity of the database

Checking the integrity of the database should always be done after a database server crash. The service osverifydb should be started after the server and the ObjectStore service have been restarted so that the transaction-logfile could be processed. If necessary, a copy of the database should be created after the startup and osverifydb should be run over it to resume operation as soon as possible.

Removing deleted objects

Objects are only "logically" deleted during operation. This means that they are marked as deleted. In order to really delete them from the database, a procedure as described here is necessary.

Backup, create copy of a database

Databases can be backed up online (i.e. without interrupting access) or offline. In addition, a distinction must be made as to whether the backed-up database alone is in a consistent state, or whether the ObjectStore transaction log must also be backed up and restored in an emergency.

Offline backup

The database cannot be accessed during the offline backup. The database transaction log does not need to be backed up when the database is taken offline.

It is not necessary to close the ObjectStore® server.

Online backup

There are three ways to secure a database without interrupting access:

• Snapshot of the file system
• osbackup
• oscopy

Snapshots

ObjectStore supports the backup of the database via snapshots of the file system, provided that the snapshots can be created via command line. This applies for example to Microsoft VSS (Windows Shadow-Copy in NTFS) or NetApp. It must be ensured that the database and the transaction log are contained completely and consistently in the snapshot. This can be realised either by shutting down the ObjectStore Server or by switching the ObjectStore Server into "quiet mode". The tool for this is ossvrquiet. An ObjectStore server and an executable or batch file with the backup commands must be specified. The maximum time in quiet mode (i.e. the time in which the snapshot must be created) is 180 seconds by default and can be changed with the environment variable OS_QUIET_MODE_TIMEOUT_SECONDS. To ensure that the last transactions from the log have been propagated to the database, an ossvrchkpt should be executed before ossvrquiet.

The following code can be used to create a consistent snapshot with Windows VSS. The script must be executed on the database server. The example assumes that the database transaction log is somewhere on drive c: and the database is somewhere on drive d::

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

After the call, previous versions and thus backups of the database and the transaction log can be accessed using NTFS means (e.g. Windows Explorer or third-party backup tools).

The above command does not work for ObjectStore 32-bit on a Windows 64-bit system. An error message like:

"Error: Unexpected error: Class not registered"

This is due to the "sandbox" in which 32-bit applications run under Windows 64-bit (keyword WoW64). However, the command can also be used for ObjectStore 32-bit via the following diversion:

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

To restore the created backup, the ObjectStore Server services must be stopped and then the transaction log and database backup must be copied to the original locations. Now activate the services again, the data from the transaction log will be written to the database and the database can be accessed again.

osbackup

An online backup tool from ObjectStore are the osbackup and osarchive. The database can still be used during this period, but the backup will take longer. Please consult the documentation of ObjectStore® if you want to use osbackup/osarchive. In case of doubt, please contact the ClassiX® support directly.
Note: osbackup does not create a direct copy of the database, but the database is stored in its own format, which must be restored with osrestore if necessary. With osarchive, transactions are individually recreated on the backup, so that, under certain circumstances, minute-by-minute statuses can be reduced.

oscopy

Another easy way to get a database copy without shutting down the server is oscopy:

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

However, oscopy takes up a lot of resources, so that continued work during copying is severely impaired. oscopy is therefore only suitable for small databases or when not much work is being done on the server. The advantage is that the target file is immediately available as a database. Note: The database is not a 1:1 copy. During copying, empty areas of the database are physically deleted and defragmented.

oscopy works in MVCC mode, which means that a consistent snapshot of the database is copied. To achieve this, changes are not propagated from the server log to the database during the oscopy command. Many write processes during a long oscopy run can therefore result in the server log growing considerably.

Attention: When copying with oscopy, it is essential to ensure that no file exists in the target path. If an existing database file is copied using oscopy, the copy is carried out correctly, but the server log (osserver.log) grows to a multiple of the database size to be copied and the database file itself becomes larger as a result of this process (it becomes smaller again if the database is copied to a path without a target file).

This is why the target file should always be deleted before an oscopy (e.g. using del)

The ossvrchkpt command after the copy is necessary to propagate the changes from the server log to the backup database in case the backup database is to be taken offline, moved or zipped, otherwise you may be backing up an incomplete backup.

Recovery, restoring the database

Packing of databases from 5GB

If the database is too large for the usual zip programs for Windows, it can be packed with GZip or 7-zip.
A setup was created that packs the databases with GZip when double-clicked. The setup can be found here.

Procedure oscopy run

Objective

Copying the database with oscopy carries out an internal reorganisation in addition to copying. If the database has not been reorganised for a long time, the access times are reduced significantly with a slight increase in the database size. A prerequisite for the implementation by the customer himself is an error-free database.

Aids used

• Start possibilities for ClassiX environment (version 4.5.xxx) on 2 databases - original, and copy (here marked with placeholders dborig and dboscopy), which is created during the procedure
• A Win-32-bit computer with ObjectStore 32-bit

Execution

• Disable login to ClassiX database, log out all users
• Switching Offline
  osdbcontrol -offline dbname
• Create a copy for backup purposes with normal Windows means
• Go online
• Using Oscopy
  oscopy dborig dboscopy
  Note: oscopy uses ObjectStore to its full capacity, parallel access to other databases on this computer will take considerably longer, so nothing else should be running for the time of oscopy
• Start test ClassiX environment on dboscopy
• Take both databases offline
• copy dboscopy to dborig
• Putting the new dborig back online
• Allow login again

Backup-Script

Offline version

@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

@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 restart

Attention: Not the ObjectStore server should be restarted, but the Windows server.

It has been observed that for servers with high runtime, ObjectStore operations take longer than after server startup.

To prevent this, you should schedule a server restart at least once a month.

In environments where there is a high level of access to the ObjectStore databases (many simultaneous users or many small accesses) it may be worthwhile to increase the restart interval up to once a week.

Raise log level

The server writes a log that can be useful for troubleshooting corruption. The log is usually located in the installation directory of ObjectStore under /temp/osserver.txt. The location can be changed by setting %OS_TMPDIR% and the name of the log file can be configured using %OS_SERVER_OUTPUT_LOG_NAME%. If you can't find the file, check the two environment variables and if necessary use the ProcessExplorer to examine the open file handles of the osserver.exe process (admin rights required).

The log level can be set to debug by checking the registry entry ImagePath of the ObjectStore Server service of:

C:\ODI_2013.0(U20)_VS2012\OStore\BIN\OSSERVER.EXE

is changed to :

C:\ODI_2013.0(U20)_VS2012\OStore\BIN\OSSERVER.EXE -d 1

Then the server service must be restarted and then the server logs at debug level. If you open the properties window of the ObjectStore server service in the service administration, you should be able to see the changed path under "Path to EXE file:".

Attention: This causes the server's log file to grow much faster and should be deleted at regular intervals.