The Database Server


The Mimer SQL database server is a single, multi-threaded process. Clients using TCP/IP can access the server. For clients running on the same platform, a shared-memory based communication method is used.

The standard Mimer SQL database server program is named mimexper (there is also an in-memory database server available, named miminm.) It is controlled using the mimdbserver command, or mimcontrol command. When running the dbinstall command, the database server is automatically created and started for operation.

On macOS there also is a specific GUI application provided to handle the database administration from the computer desktop. This is the Mimer SQL Database Admin app.

The following is the operations that can be performed from the command line of the Terminal application.

To manually start the database server use the command as follows:

# mimdbserver -s <database name >


To stop the database server program, use the following command:

# mimdbserver -t <database name>


The target database name can be assigned to the environment variable MIMER_DATABASE. If defined that way the database name can be omitted from the command line.

Database home directory

The database home directory is the catalog where the SYSDB system databank file resides. This path is registered in the sqlhosts file, usually located as /etc/sqlhosts. By using the environment variable MIMER_SQLHOSTS, another file can be pointed out as being the sqlhosts file.

The database home directory can be located using the following command:

# mimpath <database name>


The Mimer SQL system databank SYSDB file will be located in the database home directory and other databanks will typically be located relative to it, see Locating Databank Files in System Management Handbook.

Logging database events

Database events are written to the mimer.log file, located in the database home directory.

The following command can be used to list the log-file:

# mimdbfiles -L <database name>

Configuring a database server

The configuration file for an installed Mimer SQL database server is named multidefs and is located in the database home directory.

The content of the configuration file can be seen by using the command:

# mimdbfiles -C <database name>

The multidefs parameter file

The multidefs file holds the parameters adjustable for a database server. It is automatically created when creating the database using the dbinstall command. A default setup is made, but further configurations can be made manually if needed. Refer to the Mimer SQL System Management Handbook or open a discussion with Mimer SQL support representative.

If the multidefs file is not found when starting a database server, a new file will be created using the default values for all parameters. The actual default values used may vary and may depend on factors like machine type and the amount of physical memory available on the machine.

The multidefs settings can be modified after the database is created, and will be taken into account at the next server startup.

The following is an example of a default multidefs parameter file:

-- Mimer SQL version 11.0.7F Beta Test parameters generated 2023-03-17 00:01

Databanks          100         # Max # of databanks (20-1000)

Tables             4000        # Max # of tables (500-1000000)

ActTrans           20000       # Max # of active trans (500-1000000)

SQLPool            1000        # Initial SQLPool (400-8388607 kB)

RequestThreads     8           # # of request threads (1-100)

BackgroundThreads  3           # # of background threads (1-100)

TcFlushThreads     1           # # of t-cache flush threads (0-20)

Users              100         # Max # of logged in users (1-5000)

DBCheck            1           # DB check [0=index, 1=all, 2=immediate,

                                 3=im. index, 4=im. all] (0-4)

Pages4K            203347      # # of 4K bufferpool pages (11-2147480000)

Pages32K           18465       # # of 32K bufferpool pages (7-2147480000)

Pages128K          2151        # # of 128K bufferpool pages (0-2147480000)

DelayedCommit      0           # Delayed commit [0=Off, 1=On, 2=Disabled]


DelayedCommitTimeout 100       # Delayed commit timeout in milliseconds


GroupCommitTimeout 2           # Group commit timeout in milliseconds (0-20)

Oper                           # Receivers for messages

DumpPath           .           # Path for dump directory

TCPPort            inetd       # TCP/IP port

MaxSQLPool         216000      # SQLPool max size (2400-16777215 kB)

NetworkEncryption  1           # Client/server encryption [0=Off,

                                 1=Optional, 2=Required] (0-2)

MemLock            0           # Lock bpool in memory [0=Off, 1=On] (0-1)

MiniDump           1           # Small bufferpool dump (no page content)

                                 [0=Off, 1=On] (0-1)

BackgroundPriority 0           # Thread priority [0=Off, 1=On] (0-1)

AutoStart          1           # Autostart [0=Off, 1=On] (0-1)

DumpScript         ./ %p  # Dump Script

IOQueue            1024        # Max # of concurrent I/O requests (0-65535)

ServerType         3           # Server type [3=mimexper, 7=miminm] (3-7)


Comments in the file are introduced by the character sequence --, or by the character ! or #.

A new multidefs file can also be generated manually. If no multidefs file is located in the database home directory, the following command will generate a new one, having the default values:

# mimdbserver -g <database name>

The parameters in multidefs




Specifies the maximum number of databank files that the database server can have open at any one time.


Specifies the maximum number of tables that can be accessed simultaneously by the database server.


Specifies the maximum number of transactions that can be active in the database server


Initial size of the SQLPool area in K bytes. This area contains information about each session, i.e. opened tables and databanks, compiled SQL programs, etc. The SQLPool area will expand automatically if it is too small, but it will not be larger than MaxSQLPool.


The number of threads in the database server that can serve client requests.


The number of background threads in the database server.


Extra threads that run in the background to help clear the transaction cache. This is beneficial for systems with long-running transactions. The thread keeps the size of the transaction cache down by deleting records that are no longer used.

When there are no long running transactions the cache can be cleared efficiently without scanning the cache so in this case the thread is not needed. Default is 1 thread.

To get the same behavior as in Mimer SQL version 10.0, specify 0 threads for this parameter. For very large databases with long-running transactions more than 1 thread can be used.


The maximum number of users that are allowed to connect to the database server. This parameter should not exceed the number of users specified in the Mimer SQL license key. This number is also used to calculate the size of the shared memory region used for local database server communication. About 70 Kbytes of shared memory will be allocated for each user.


A number which specifies what kind of check that should be performed when a databank is opened which previously was not closed properly.

0 - check index pages

Index pages only are checked in the foreground while applications that access the databank waits for the operation to complete.

1 - check data pages

A full databank check (involving index and data pages) provides for more secure operations, but may take much longer to execute than an index page check. When a full check is done, the index pages are checked in the foreground and the data pages are checked in the background so there is a smaller effect on performance.

2 - Immediate restart, no check

This option performs no checking when the file is opened. The system still verifies the integrity of each page through a checksum. A few pages may have been pre-allocated and these are not reclaimed when this option is used. If the option is subsequently changed these pages will be reclaimed the next time the databank is opened.

3 - Immediate restart, check index pages

This option performs a check of all index pages in the databank in the background. This is done concurrently with other operations on the system.

4 - Immediate restart, check all pages

This option performs a check of all pages in the databank in the background. This is done concurrently with other operations on the system.

The Immediate restart options require a license key module called ‘Imm Restart’. Databank checks can be avoided by always shutting down the database server properly with the mimcontrol/mimdbserver command, especially prior to shutting down the machine.


The number of 4 Kbytes pages in the bufferpool area containing pages from the databank files. The default value of this parameter is 12.5% of the total RAM memory in the machine.


The number of 32 Kbytes pages in the bufferpool area containing pages from the databank files. The default value of this parameter is 8.33% of the total RAM memory in the machine.


The number of 128 Kbytes pages in the bufferpool area containing pages from the databank files. The default value of this parameter is 5% of the total RAM memory in the machine.


This option controls how quickly a transaction commit is secured on disk. It greatly affects the performance of the database server. For example, if a single user commits two transactions in quick sequence the database server may use a single I/O to secure both transactions when delayed commit is on. Transactions are never reordered by using the delayed commit option. I.e. it is not possible for a later transaction to be secured on disk before an earlier one. The database is thus always returned to a consistent state after a machine crash. However, if a transaction has been committed but not yet written to disk it will be lost if the database server or machine goes down in an uncontrolled fashion. Transactions that use the XA transaction protocol are automatically committed with delay commit disabled. The delayed commit option can be set to one of the following:

0 - Default off

In this mode delayed commit is not used unless a transaction is set to use delayed commit by the application. This is the default.

1 - Default on

In this mode all transactions where the delay mode has not been explicitly set are delayed. The transaction will be secured within the time-out period specified. If other transactions are committed before the time-out occurs the transactions may be combined into a single I/O to boost performance.

2 - Disabled

In this mode all transactions are secured to disk immediately and the application will not regain control after a commit until the transaction has been secured. This option overrides any application settings for delay commit.


This specifies the number of milliseconds to wait before the transaction is written to disk. If a value of zero is specified transactions are not flushed until the server determines that the commit set page is full. In general, this is not recommended as transactions are likely to be lost if there is an uncontrolled machine stop. Default is 100 milliseconds.


How many milliseconds to wait for other transactions to commit before proceeding with first transaction. If another transaction arrives within the timeout period if will be grouped with existing transactions before they are committed together with a single I/O rather. This improves overall performance but the delay prolongs commits time on a system with low load. Default is one millisecond.


This parameter gives a list of host system users, i.e. operators, or e-mail addresses that should receive e-mail notification of serious problems with the database server.


This parameter may specify an alternate path for the dump directories. The default is to create dump directories under the database home directory.


Specifies how the database server should handle incoming TCP/IP connection requests. If this parameter is set to - (a single dash), the TCP/IP capability will be disabled for the database server. The TCPPort parameter is, by default, set to inetd - which means that the TCP/IP port server program, mimtcp, will be used for establishing a connection to any Mimer SQL database server (of version 8 and later). In this case clients may connect to the port to which mimtcp listens, usually 1360, and the handshake will be passed over to the requested Mimer SQL database server. If a TCP/IP port number is specified, the database server will listen directly to that port.


The maximum size (in kilobytes) of the SQLPool. The SQLPool memory area grows dynamically, but the size will never exceed this parameter. Use this parameter to control the maximum virtual size (maximum page file usage) for the database server process.


Controls the use of encryption of network communication over TCP/IP between server and clients.

0 = Network encryption disabled

Network encryption is not supported or not used.

1 = Network encryption preferred

Network encryption is enabled for version 11 clients. Older clients use unencrypted network communication. When this setting is used, older clients without support for network encryption are allowed to communicate with the database server over TCP/IP.

Use this option when there is a mix of older and newer clients that communicate with the database server over TCP/IP.

This is the default value.

2 = Network encryption required

The database server requires all clients to use encrypted communication when communicating over TCP/IP.

Clients that do not support encryption are rejected at login with error code -18531.

This option is recommended over option 1 when possible (i.e. when there are no older clients that need to be supported.)


A number which specifies whether the bufferpool and communication buffers should be locked in memory (1) or not locked in memory (0).


Small bufferpool dump (no page content), if enabled.


Specifies if the background threads should run at a higher priority than other server threads. During certain circumstances like in situations where the background threads cannot manage to shorten a transaction queue this can be an alternative.


By default, this parameter is set to 1 which indicates that the database should be started automatically when the operating system goes into multi-user mode.

If the parameter is set to 0 the database will not be started automatically at a computer restart.


If the database server goes into an erroneous and unrecoverable state, it will produce dumps of the current internal database structures before it goes down. If this situation occurs, it is of great importance for the error detection process to get a macOS kernel stack trace from the location where the error was located.

By defining this parameter to a command that can produce a kernel trace stack information will be automatically generated to mimer.log.

The %p option used in the example setting in the beginning of this section, is used to get the current process ID as a parameter to the command given.


Specifies the maximum number of concurrent IO requests queued to the operating system. Default is 1024, but more advanced disk systems such as SAN’s, battery backed caching IO controllers, PCI Express connected SSD’s and NVMe SSD’s can make use of larger queues. This can give a significantly higher database performance, but specifying a too large queue can overload the IO subsystems. Maximum queue length is 65535.


This option decides which Mimer SQL database server program that should be started to operate the database files for the database:

3 - mimexper

The Mimer SQL Experience database server. This is the standard database server.

7- miminm

The Mimer SQL In-memory database server.

Automatic database start and stop

When Mimer SQL is installed, autostart is automatically enabled. The mimservers program will start or stop all local Mimer SQL v11.0 servers defined in the sqlhosts file. The setup is done by using the mimautoset command, invoked during installation. For details, see the man-page for mimautostart. To exclude a server from the automatic start/stop procedure, set the AutoStart parameter in the multidefs file for that server to 0. To see the autostart installation made, the following command can be used:

# mimautoset -lv


The mimservers command is used to manage all database servers installed. The following command will list the state for all database servers:

# mimservers -b

Remote database access

Database TCP/IP connect dispatcher

When a Mimer SQL database is created using the dbinstall command the definitions needed for remote access to the database is installed automatically.

When the setup is made, the mimtcp command is invoked by the operating system when an incoming Mimer SQL database connection request is identified on the target TCP/IP port. It finds out the database name in the handshake message and redirects the connection to the target database using the registered information in /etc/sqlhosts.

To see the setup made, the following command can be used:

# miminetd -l


Note:It is possible to let a Mimer SQL database server listen directly to a TCP/IP port, i.e. not using the mimtcp redirecting function. This is achieved by changing the TCPPort parameter in the multidefs file from the default inetd value to the actual port number used, usually 1360.

The mimtcp command

The mimtcp command is used to handle the handshake between a remote client and a database server. It should be used with, and be invoked by, an Internet Service Daemon - see Networking Setup.


The overall syntax for MIMTCP is:

mimtcp [-l [-f filename]


mimtcp [--log [--file filename]


mimtcp [-v|--version] | [-?|--help]

Command-line Arguments

You can use the following arguments with MIMLOAD.





Enable logging.

-f file


Define a log file.



Display version information.



Show help text.

If mimtcp is used without any option, no logging is performed by the program. If a string value is given in addition to the -l option, that value will be used as the log file. If the -l option is used without a value, the filename mimtcp.log will be used that will end up in the root home folder under a sub directory called .mimer_log.

The following example will start mimtcp with logging using the default log file, located in ~/.mimer_log/mimtcp.log:

# mimtcp -l

Services setup

The /etc/services file holds the Internet network services list. The list is a mapping between names for internet services, and their underlying assigned port numbers and protocol types. The following excerpts from the file shows the header for the list and the mimer entries:

# Port Assignments:


# Keyword Decimal Description References

# ------- ------- ----------- ----------

mimer     1360/tcp # MIMER

mimer     1360/udp # MIMER


Having this definition done, the name MIMER can be used instead of 1360 when dealing with services.

Networking Setup

The miminetd command is used to handle the networking setup. This is done automatically during the installation.

Here are the miminetd options and a common setup display:

# miminetd "-?"


   miminetd [-i|-l] [-q|-d]

   miminetd [-v|-?]



   -i    Install.

   -l    List status.

   -q    Quiet operation.

   -d    More detailed, verbose operation.

   -v    Display version information.

   -?    Display this usage text.



   Command used to integrate Mimer SQL in the operating system

   Internet services like systemd/inetd/xinetd/launchd.


# miminetd -l

miminetd: launchd: existing /Library/LaunchDaemons/com.mimer.mimersqlPortListen.plist is up-to-date

miminetd: launchd: Mimer SQL is installed in the launchd environment (/Library/LaunchDaemons/com.mimer.mimersqlPortListen.plist)

miminetd: launchd: daemon is executing

miminetd: launchd: daemon found as /sbin/launchd


Using odbc.ini data sources

The standard ODBC odbc.ini file and the Mimer SQL sqlhosts file are related to each other in both being repositories for databases, or data sources. When using ODBC to connect to a Mimer SQL database, data source names (DSN) defined in the odbc.ini file can be used. In this case the odbc.ini file is accessed first, and only if needed the ordinary database lookup is done in the /etc/sqlhosts file.

When a Mimer SQL database is created using the dbinstall command, it gets defined in the sqlhosts file in the LOCAL section. For example, if creating the database named my_db with the home directory /Library/Application Support/MimerSQL/my_db, it will end up in /etc/sqlhosts like this:


  my_db          /Library/Application Support/MimerSQL/my_db


If an ODBC Driver Manager is installed, there will also be an option to automatically define it in the global odbc.ini file, usually located as /etc/odbc.ini. Such a definition will look like the following:


Driver    = /usr/local/lib/libmimodbc.dylib

Database  = my_db

Host      = localhost

Port      = 1360

Trace     = No

TraceFile = /tmp/mimersql.log


We can now look at a simple example where the Perl DBI/DBC-ODBC interface is used to connect to a Mimer SQL database:

#!/usr/bin/perl -w

use DBI;





$dbh = DBI->connect($data_source, $username, $auth) or die $DBI::errstr;

print "Connected! ($dbh)\n";


In this case the my_db definition in the odbc.ini file will be used, more precisely the attributes Driver, Database, Host and Port are used:


The ODBC driver to be used, specific to each database kind. For Mimer this is the libmimodbc.dylib shared library.


The name of the database to be accessed, as defined in the sqlhosts file on the node where the database resides.


The name of the computer node where the database resides. If this attribute is left out, the value of the Database attribute will be looked up in the /etc/sqlhosts file for further information about the connection setup.


The port number to used for the database communication. If this attribute is left out, the default '1360' will be assumed.

Assuming a Mimer SQL database on a remote computer is defined in the REMOTE section of the sqlhosts file as follows:


   prod_db    tcp   '' 1360


Also, assuming we have the following DSN defined in the odbc.ini file:


Driver = /usr/local/lib/libmimodbc.dylib

Database = prod_db


To connect to the prod_db database on the node using the program example above, we can simply change the data source definition in the program above to:



The data source remote_prod will be looked up in odbc.ini. The database name prod_db will be encountered, but there is no host defined so an attempt will be made to find appropriate connection information for the given database in the sqlhosts file. When the node and the port 1360 are identified for the database name, the connection will be completed.

The ODBCINI environment variable can be used to point out the odbc.ini file to be used.

Note:Tabs are not allowed in the odbc.ini file.