OpenLM Database optimal configuration – recommendations

Our recommendations

• If the binary log is enabled, the database user needs to have SUPER privileges in order to run some upgrade scripts.
  To verify if the binary log is enabled run the following command:

  SHOW VARIABLES LIKE 'log_bin';

   

• To Verify if the current user has SUPER privileges run the following script:

  SELECT *
  FROM INFORMATION_SCHEMA.USER_PRIVILEGES
  WHERE PRIVILEGE_TYPE = 'SUPER'
  AND REPLACE(GRANTEE,'''','') = CURRENT_USER();

• It is possible to allow functions/procedures creation by enabling the following option : log_bin_trust_function_creators. To check if it is enabled – run the following script :

  SHOW VARIABLES LIKE 'log_bin_trust_function_creators';

• Another option is to disable binary logging if replication is not enabled or point-in-time recovery is not needed.
• For compilers that perform multiple checkouts/check-ins in a second, we recommend 25%-50% stronger hardware.
• VM Administrators should make sure that the hosting server is capable of accommodating the required resources.
• When seeing a low performance in DB queries, please check the disk queue.
• We strongly recommend placing the DB in the same Data Center as OpenLM Server.
• See recommendations for MS SQL Server below.
• For MySQL we provide a sample configuration file for Windows (my.ini) & Linux (my.cnf) that should be revised by DBA.
• VM network controller should be available for each network card.
• In the case of a big DB (from 25GB and up) and big load, each DB should have 3 files and 3 VM disk controllers for the: db file, log file and tmp file.

Best practices for using MySQL

1. Use the latest 5.7/8 MySQL release.
2. In order to utilize the system’s resources MySQL requires its configuration file (my.cnf/my.ini) to be set with correct values. Otherwise, MySQL will not take advantage of its hosting machine’s resources. We recommend some settings – please see our suggestions for configuration files archived in .zip format according to your system size:

8GB_4Cores_Windows

16GB_8Cores_Linux

16GB_8Cores_Windows

24GB_8Cores_Windows

Best practices for using MS SQL Server

1. Customers need to apply a maintenance plan consisting of:
a) Periodic Statistics Update
b) Periodic Rebuild or Reorganization of Indexes
DBAs need to apply company maintenance policy also for OpenLM DB. In case such does not exist, a public package can be applied (Here is one).

2. Recommended memory allocation to MSSQL Server running (almost) exclusively on a windows machine is no more than 80% of total machine memory.

3. OpenLM database should have the is_read_committed_snapshot_on parameter set.

To check if it is set:

SELECT is_read_committed_snapshot_on FROM sys.databases
WHERE name= 'YourDatabase'

To set:

DECLARE @sqlCommand varchar(1000)
DECLARE @db_name varchar(50)

SET @db_name = 'YourDatabase'

SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET ALLOW_SNAPSHOT_ISOLATION ON '
EXEC (@sqlCommand)

SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET SINGLE_USER WITH ROLLBACK IMMEDIATE '
EXEC (@sqlCommand)

SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET READ_COMMITTED_SNAPSHOT ON '
EXEC (@sqlCommand)

SET @sqlCommand = 'ALTER DATABASE ' + @db_name + ' SET MULTI_USER '
EXEC (@sqlCommand)

4. For better performance, we recommend installing tempdb, databases and log files on separate logical (and in some cases – even physical) disks.
A solid installation would have:

a) 1- disk for tempdb data (ssd configuration is recommended)
b) 1- disk for system DBs (msdb, model, master)
c) 1- disk for all logs (including tempdb logs)
d) 1- disk for all DBs Data

5. tempdb has a critical role, having all parameters, temporary tables and executing sorts and aggregations. Number of tempdb data files is recommended to be as number of processors – up to 8 (more will have no effect or bad influence on performance).
6. Autogrowth units of database files is set by default to percent, which is dangerous. A good practice would be to use MB units, based on a predicted growth multiplied by record size. In any case, setting alerts on disk size is recommended.
7. It is recommended to set log size upfront.
8. A regular backup program is recommended in order to be able to resume crashes and control log files growth. Shrinking a database is a bad practice and is not recommended.

Best practices for using MariaDB

Note: Backup the my.ini before changing the file:

8GB :

16GB :

24GB :

tmp_table_size=3G