+

Search Tips | Advanced Search

For up-to-date product documentation, see the IBM MobileFirst Foundation Developer Center.


Internal runtime databases

Learn about runtime database tables, their purpose, and order of magnitude of data stored in each table. In relational databases, the entities are organized in database tables.


Database used by MobileFirst Server runtime

The following table provides a list of runtime database tables, their descriptions, and how they are used in relational databases.

Table 1. Common runtime database tables
Relational database table name Description Order of magnitude
LICENSE_TERMS Stores the various license metrics captured every time the device decommissioning task is run. Tens of rows. This value does not exceed the value set by the JNDI property mfp.device.decommission.when property. For more information about JNDI properties, see List of JNDI properties for MobileFirst runtime
ADDRESSABLE_DEVICE Stores the addressable device metrics daily. An entry is also added each time that a cluster is started. About 400 rows. Entries older than 13 months are deleted daily.
MFP_PERSISTENT_DATA Stores instances of client applications that have registered with the OAuth server, including information about the device, the application, users associated with the client and the device status. One row per device and application pair.
MFP_PERSISTENT_CUSTOM_ATTR Custom attributes that are associated with instances of client applications. Custom attributes are application-specific attributes that were registered by the application per each client instance. Zero or more rows per device and application pair
MFP_TRANSIENT_DATA Authentication context of clients and devices Two rows per device and application pair; if using device single sign-on an extra two rows per device. For more information about SSO, see Configure device single sign-on (SSO).
SERVER_VERSION The product version. One row


Database used by MobileFirst Server administration service

The following table provides a list of administration database tables, their descriptions, and how they are used in relational databases.

Table 2. Common administration database tables
Relational database table name Description Order of Magnitude
ADMIN_NODE Stores information about the servers that run the administration service. In a stand-alone topology with only one server, this entity is not used. One row per server; empty if a stand-alone server is used.
AUDIT_TRAIL Stores an audit trail of all administrative actions performed with the administration service. Thousands of rows.
CONFIG_LINKS Stores the links to the live update service. Adapters and applications might have configurations that are stored in the live update service, and the links are used to find those configurations. Hundreds of rows. Per adapter, 2-3 rows are used. Per application, 4-6 rows are used.
FARM_CONFIG Stores the configuration of farm nodes when a server farm is used. Tens of rows; empty if no server farm is used.
GLOBAL_CONFIG Stores some global configuration data. 1 row.
PROJECT Stores the names of the deployed projects. Tens of rows.
PROJECT_LOCK Internal cluster synchronization tasks. Tens of rows.
TRANSACTIONS Internal cluster synchronization table; stores the state of all current administrative actions. Tens of rows.
MFPADMIN_VERSION The product version. One row.


Database used by MobileFirst Server live update service

The following table provides a list of live update service database tables, their descriptions, and how they are used in relational databases.

Table 3. Live update service tables
Relational database table name Description Order of magnitude
CS_SCHEMAS Stores the versioned schemas that exist in the platform. One row per schema.
CS_CONFIGURATIONS Stores instances of configurations for each versioned schema. One row per configuration
CS_TAGS Stores the searchable fields and values for each configuration instance. Row for each field name and value for each searchable field in configuration.
CS_ATTACHMENTS Stores the attachments for each configuration instance. One row per attachment.
CS_VERSION Stores the version of the MFP that created the tables or instances. Single row in the table with the version of MFP.


Database used by MobileFirst Server push service

The following table provides a list of push service database tables, their descriptions, and how they are used in relational databases.

Table 4. Push service tables
Relational database table name Description Order of magnitude
PUSH_APPS Push notification table; stores details of push applications. One row per application.
PUSH_ENV Push notification table; stores details of push environments. Tens of rows.
PUSH_TAGS Push notification table; stores details of defined tags. Tens of rows.
PUSH_DEVICES Push notification table. Stores a record per device. One row per device.
PUSH_SUBSCRIPTIONS Push notification table. Stores a record per tag subscription. One row per device subscription.
PUSH_MESSAGES Push notification table; stores details of push messages. Tens of rows.
PUSH_MESSAGE_SEQUENCE_TABLE Push notification table; stores the generated sequence ID. One row.
PUSH_VERSION The product version. One row.

For more information about setting up the databases, see Set up databases.

Parent topic: Installation reference