Many people once liked to put the test database and formal database on one server, which could save resources. Although the formal and test are divided into two instance configurations, there will be no security issues, but there will be many problems in performance and maintenance.
1. Maintenance. However, for formal servers, services are running and SLA restrictions are imposed. So when we put them together, the test server loses the flexibility.
2. performance: for SQL Server, We can restrict the CPU and memory from the configuration, but cannot limit the IO (unless you put the test and the formal database on a different physical disk, So that I/O can be separated, i/O restrictions cannot be implemented if the disk is placed on the same disk. This is fatal. I encountered an accident when I first joined the company and was not very familiar with databases. I got a call saying there was an application.ProgramSlow response. At that time, I wanted to log on to the server to check the resource utilization rate, and the result was never logged on. After logging on to SQL Server, I found that a bunch of waits were generated and blocked. The root cause was Io. Later I found that there was another instance on the server, and a large number of applications were running. Call the developer to confirm they are testing. This is because of such a test, which leads to problems in competition between the formal environment and the test environment resources.
Then the test instance was stopped, and the Environment recovered one minute later. The following figure shows how to remove the test instance.
Therefore, the formal server and the test server must be separated. Multiple test instances can be installed on one test server.