Skip to main content

All, what is best practice for the SQL install when deploying CommServe? If I were deploying a high performance SQL installation I would typically put OS, SQL DB, SQL Logs, Temp DB all on separate disks (not partitions on same disk). Is this best practice, desirable or even do-able with CommServe?

@gleano

 

We are installing agent on same disks and during installation we can’t change the disk for separate installation to put OS, SQL DB an SQL logs, Temp DB in separate disks. 

 

As per the commvault recommendation.

 

The software installation requires 10 GB of disk space on the operating system drive. This space is used for temporary files copied during the installation or upgrade of the CommServe and Microsoft SQL Server software.

 

You can follow the below document for further information. 

 

https://documentation.commvault.com/2022e/expert/2801_commserve_server_system_requirements_windows_02.html


@nishas  Thanks for your reply. Are you saying these parms cannot be selected on the install? If so, is it possible to use a previously configured instance of SQL on the server being used for CommServe? Not shared OR change the location of the TempDB and Logs directory after CommServe installation?


Hi Glenno,

 

SQL Server can be certainly installed prior to installing the CommServer. We have the following documentation available;

 

For non-cluster environments;

https://documentation.commvault.com/2022e/expert/1724_pre_installing_microsoft_sql_server_software_on_non_cluster_environment.html

 

For cluster environments;

https://documentation.commvault.com/2022e/expert/1728_pre_installing_microsoft_sql_server_software_on_cluster_environment.html

 

As for any additional Best Practices. It will be ideal to follow Microsoft’s Gold Standard, as you have already mentioned, move the main databases to their own dedicated high performance disk and so on. This is definitely feasible with both a pre-install SQL Server Instance and with our automatic installation once the CS has been successfully installed;

 

https://documentation.commvault.com/2022e/expert/4737_changing_location_of_commserve_database_files.html

 

The above documentation only relates to moving the CSDB to a different location/drive. For any other DBs like the TempDB we would follow the Microsoft KB;

 

https://learn.microsoft.com/en-us/sql/relational-databases/databases/move-system-databases?view=sql-server-ver16


Thank you Javier! Fantastic reply. I believe the cost of the SQL licence is part of Commvault licensing so I’m guessing best to do the install with SQL baker in AND then change the DB, logs and TempDB options? Many thanks for the links! Lastly Commvault will support an instance of the application deployed on a SQL install different to the baked in settings?


You are definitely correct. Using the baked in version will benefit from having the SQL Server already licensed via the Commvault Software. You can then perform the required changes to align to SQL best practices.

 

Both the Commvault installed and the pre-deployed version will have a similar level of Support from Commvault.

 

Further details about the Microsoft SQL Server EULA included within the Commvault software can be found within our documentation;

https://documentation.commvault.com/2022e/essential/50060_microsoft_sql_server_eula.html


Another quality reply and your time to do so was greatly appreciated. Thank you!


@Javier If I can please clarify one thing. When using LiveSync is there anything else to be moved as doesnt LiveSync create a second SQL instance somewhere?  Many thanks!


Hi Glenno,

 

When configuring CS LiveSync, we will be effectively installing another CS that will act as standby and will receive regular CSDB replications to keep the Database in-sync.

 

During the installation of this Standby, we will install both Instance002 (the SQL iDA in charge of the DB replication jobs) and Instance001 (the CS instance that will remain passive most of the time) all together, the configuration during the installation cannot be modified.

 

Having said that, once the Passive Node is fully installed, the databases could be moved to a different location as long as the Backup and Replication CS LIveSync schedules are also modified to account for these changes (mainly the restore/replication part). At that point the Passive CS can be treated as any other CS, it will just have its Instance001 services stopped (since only 1 CS entity can exist in the environment, and it will be a 1:1 copy of the production CS, including its name) and Instace002 active as a SQL iDA Client to allow for the replication.

 

The following link defines what to expect from a Default CS LIveSync Deployment once completed;

https://documentation.commvault.com/2022e/expert/102845_verifying_default_setup.html

 

And the following one describes what to plan to get CS LiveSync Deployed on an environment;

https://documentation.commvault.com/2022e/expert/102842_planning_for_commserve_livesync_in_windows_environment.html


Thanks @Javier I have already deployed LiveSync in the test environment but will be rebuilding from scratch and re deploying everything again before testing for prod deployment. Moving DB’s on the secondary instance sound “interesting” 🙂 Will see how i go! Many thanks

EDIT: The destination client and instance are not editable in the system created Livesync schedule tasks.

 


Reply