SDBTech-KSS-SHM in /tmp causes UNKNOWN state when deleted

[richard_howard]

MaxDB puts a file in the /tmp directory on HPUX:

-rw-rw---- 1 sdb sdba 168 Apr 18 07:12 SDBTech-KSS-SHM-<SID>

By it's nature, the /tmp file system is routinely cleaned and files are deleted at random by our Unix Admin Team. If this file is deleted, the DBM GUI will show an UNKNOWN state. That means this file needs to be protected but why would you put a protected file in a /tmp file system.

Are there options to this? How are others avoiding their Production liveCache going into an UNKNOWN state?

[markus_doehr2]

Is this a SAP installation? Usually those files are put under /usr/spool/sql or /var/opt/sdb

Markus

[richard_howard]

We upgraded this past weekend to SCM 7.0, which included the MaxDB 7.7 upgrade, as well.

DBMServer 7.7.07 Build 020-123-236-782

We opened a message with Support and the response was:

"there is no option to change this location"

[richard_howard]

Also to mention ...

We migrated from a PA-RISC server to IA64 before beginning our SCM 7.0 Upgrade. As part of that migration, we installed MaxDB for SCM 4.1 on IA64. This is a 7.5 Build 21 install. We then load it with the SCM 4.1 liveCache data that we migrated through an export into Oracle.

Then as part of the SCM 7.0 Upgrade, we upgrade to 7.7:

/SCM70/51036865_2/BS_7_SR1_liveCache_7.7.04_Bd._29/DATA_UNITS/LC_HPUX_IA64/ and execute the command u201C./SDBUPD u2013d L12 u2013u ******,******

We don't know for sure if it's the initial install of 7.5 Build 21 that set the path to /tmp or if it's the subsequent upgrade that set that path. We are going to test that this week.

The bigger question is whether there is a method for us to now change that path to another location like /var/opt/sdb?

[former_member229109]

Hello,

1. The /etc/opt/sdb is file of the database register.

In /usr/spool/sql/ini is the location of the database register file too.

The database register files will be written to "config" directory as of database 7.5 installation.

2. "SDBTech-KSS-SHM-<SID>' files - located in /tmp on HP server.

The liveCache kernel creates a "mapping object" during startup, which is addressed via a regular file "/tmp/SDBTech-KSS-SHM-<SID>".

The shared memory KSS (Kernel Shared Segment) is owned by sdb/sdba with permissions::

-rw-rw 1 sdb sdba

The file /tmp/SDBTech-KSS-SHM-<SID> could be removed by "root" during running a custom script to delete files in /tmp.

The liveCache <SID> then need to be restarted for the missing file to be created properly.

3. You could modify the script to exclude deletion of the files with name started with string 'SDBTech-KSS-SHM' in /tmp directory, for example.

May be you have a master file exemption list used by your cleanup script, and you could add SDBTech-KSS-SHM* to the list so that none of your liveCache systems will have this file deleted.

What is your SAP message number?

Thank you and best regards, Natalia Khlopina

[richard_howard]

When this file is deleted from /tmp, dbmcli will respond like this ...

hostname> dbmcli -d L12 -u control,control db_state

OK

State

UNKNOWN