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.
Hi Glenno,
SQL Server can be certainly installed prior to installing the CommServer. We have the following documentation available;
For non-cluster environments;
For cluster environments;
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;
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;
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!
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;
Thanks
EDIT: The destination client and instance are not editable in the system created Livesync schedule tasks.
Reply
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.