Oracle database best practices
For best results, you should configure and maintain your Oracle database according to the vendor's requirements and use the Jive best practices.
- If you're setting up new systems, the Core and Activity Engine databases can be set up as typical OLTP databases. Set up the Analytics database using the OLAP template.
- Oracle JDBC Drivers must be installed on the application services before the Jive installation. For more information, see Oracle database drivers and configurations.
- To ensure good performance, set the following JVM property on each of the web application nodes:
-Doracle.jdbc.maxCachedBufferSize=12
-
Ensure that the target database allows the Jive application's Setup wizard access to create tables. After you install the Jive application, you finish the installation (or upgrade) by using Jive's Setup wizard to connect to the target database. The Setup wizard creates or upgrades the tables it needs. So, you need to ensure that permission to create tables is granted, at least until the upgrade or installation is completed and the application has been restarted.
For example, if you are using an Oracle database for a new installation, you'll be creating a user representing a schema. That schema will be empty until the Setup wizard creates tables in it. Here's an example of a script for creating such a user:
CREATE USER coredb IDENTIFIED BY changeme DEFAULT TABLESPACE jivedata; GRANT CREATE SESSION, CREATE TABLE, CREATE VIEW, CREATE SEQUENCE, CREATE PROCEDURE, CREATE SYNONYM, CREATE TYPE to coredb; ALTER USER coredb QUOTA UNLIMITED ON jivedata;
The username can be any legal Oracle identifier –
coredb
is just an example. The application does not require a dedicated tablespace, but many DBAs have that practice. The tablespace must be created separately. For more information about theCREATE USER
statement, refer to the Oracle documentation.CAUTION:The database user must not be granted view access to any schema other than the one it owns. During upgrades, the application reads metadata about its tables defined in the database. Since the application does not know what the default schema is, it may inadvertently retrieve information about its tables defined in other schemas. If you have set up application instances by using other schemas in the same database, this can result in erroneous information being passed to the application.
If you absolutely must use a database user with access to other schemas, ensure that there is only one set of application tables defined across all schemas to prevent this object name conflict.