Manage Semaphores and Shared Memory Segments

An error is generated if you attempt to connect to or create a shared database whose size is larger than the maximum size of shared memory segments configured on your system. Also, an error is generated if the system cannot allocate any more shared memory segments.

On Linux and UNIX systems, use commands similar to the following:

• ipcs -ma to check if you have other shared memory segments using up memory, such as Oracle Database instances or other instances of TimesTen.

• ipcrm to remove a message queue, semaphore set or shared memory segment identifier. Use ipcrm to clean up semaphores or shared memory segments after a faulty TimesTen shutdown, instance crash, daemon crash or other application issues that use shared memory segments and semaphores. Use -m to remove a shared memory segment. Use -s to remove a semaphore.

• ps -eafl to see how much memory is being used by running processes.

• ulimit -a to see if there are any limits on the maximum amount of memory one process can address, maximum file size, and the maximum number of open files.

If a shared memory segment is available but is too small to hold your database, use the ttSize utility to estimate the amount of memory required for your tables and then check the values of the PermSize and TempSize attributes to verify the amount of memory established for your database. Monitoring PermSize and TempSize Attributes in the Oracle TimesTen In-Memory Database Operations Guide describes guidelines for setting the size of your permanent and temporary memory regions. If the amount of memory established for your database is too large, reset PermSize and TempSize to smaller values. See Check the Amount of Memory Allocated to a Database for more information. Another option is to increase the maximum size of the shared memory segment, as described below.

If your application is connected to your database and your database is invalidated because of a system or application failure, the database shared segment is not automatically detached from your application. The next time your application tries to use the database, the application will be disconnected from the database and the shared segment will be detached. If your application remains connected to the invalidated database and does not try to use the database, the application will not disconnect from the database and the shared segment will not be detached. To free memory and swap space, make sure you disconnect or terminate all applications that are connected to the invalidated database.

If a database becomes invalidated because of a system or application failure, and you have disconnected all applications from the database, a subsequent connection recovers the database. If recovery fails because you have run out of database space, then reconnect to the database with a larger PermSize and TempSize value than the ones that are currently in effect.

See Operating System Prerequisites in the Oracle TimesTen In-Memory Database Installation, Migration, and Upgrade Guide for more information on how to configure shared memory.