New answers tagged database-mirroring
Is really a replication what you need? it is common practive to periodically restore from production environment databases to other non-productive envs. This of course can be done in many ways but is tightly related to you development model in the company (or the testing path you have to use for your applications). If you have currently have the app_v1.0 in ...
If you have access to a db version control system (ala Red Gate), you can have it create a deployment script fairly easily. If not, just create a file and script any ddl changes you make and store them in a file, then when you are ready (and have backed up prod) you can run the script against prod to make your changes. Be aware that certain changes can ...
I don't trust mirroring 100%, but I do trust it about 99%, same with everything else. It never hurts to periodically check your mirror database and DR scheme. We test our DR plan across the board several times a year, and it would not hurt your scenario to set aside a DR test time and simulate a failure of your primary database to fully test the mirror if ...
As long as you're monitoring and alerting based on the status of the mirroring for each database then refreshing the secondary shouldn't be needed.
@mrdenny's answer is accurate that failing over one database will not result in all the other databases failing over as well. However just to give more overview of what an Endpoint is: From BOL, Connection management in Microsoft SQL Server 2005 and later versions is based on endpoints. An endpoint is a SQL Server object that enables SQL Server to ...
No it will not. The databases are failed over independently from each other. There's no harm is failing over the test database, the production database will stay where it is.
Top 50 recent answers are included