Database Configuration and Best Practices

Make sure your databases are ready before you install or upgrade Jive.

To install Jive, you'll need to set up three databases: one each for the core application, the Activity Engine, and Analytics. (While it's possible to run Jive without Analytics, any substantial installation needs to include it.) You'll find that an installation or upgrade goes more smoothly if you complete the database-related tasks first. For new installations, the database and application users must be created before installation. Follow recommended best practices for the database vendor and version selected. See the database-specific best practices below for information about how to configure your database to work with Jive.

Database Administration

We highly recommend having a skilled database administrator in charge of your Jive databases.

Locating Your Databases on Separate Servers

For large installations, it is recommended that the core application database, the Activity Engine database, and the Analytics database be hosted on separate database engines. At a minimum, disk and memory resources should be isolated for each service.

Why Separate the Core Application and Analytics Databases?

The following points explain why it's especially important for your Analytics database to be separate from the application database. Ideally, they should be stored on two separate servers. While we technically support storing the Analytics and application databases on one server, here's why it's important to ensure isolation:
  • Analytics has a very different access pattern from the application database: many streaming writes, occasional reads, and busy activity once a day when the ETL runs.
  • The storage requirements for Analytics are very different from the application database requirements. The physical size of the Analytics databases will grow much larger than the application database on busy systems. The IO profiles (the application database is a typical OLTP load, the analytics database is OLAP) and the usage profiles (potentially large result sets, aggregates and ad-hoc queries are expected on the Analytics database) also support isolation of the application and analytics resources.
  • The application database is more critical than the Analytics database. Therefore, the analytics database should not be in a position to demand resources that the core database may need.
  • The Analytics database is intended to be accessed by users running ad-hoc queries. Because the application cannot predict which queries users may run, it is possible that a bad query could execute and thus consume all of the server's capacity.

Storing Attachments

You should always configure attachments for storage using a file system provider rather than the database. Storing attachments in the database is possible, but is known to cause severe performance issues when the document store gets large and contends with the database cache. For more information about how to set up your file system storage, see Required External Components and Configuring a Binary Storage Provider.

Database Collation

The database or database instance must be configured for UTF8 collation. See the instructions for your individual database platform for instructions.