Currently we have a database server that handles the major (more than a handful of users) production databases, with a scattering of other low usage databases on the server(s) hosting the application they're associated with.
We're coming up on a "we should really upgrade to SQL2012R2 and probably Server 2012R2 at the same time (currently 2008 on the database server)" decision and I wondered how you were doing it.
Last edited by pete; 3rd April 2014 at 10:04 AM. Reason: typo
Key systems i.e. have their own Virtual Server for data, e.g. SIMS.
I have another SQL server which has 3 seemingly minor DBs on it. I have no end of hassle with this because some are for third parties and they need access, so they conflict with each other, plus you have to be really careful with permissions if you don't want vendor A to see data from vendor B. In addition to the DBs there are other bits of software tacked on too. It would have worked better if i'd given them each their own virtual app server and pointed them at the database server with fixed logins.
In this scenario, i reckon it's just as easy to install SQL onto each mini VM. Licensing issues aside, it's just easier to run a few standalone systems because when i want to bring one system down, it doesn't affect the others. More importantly, when one system is down and someone is remoting in and rebooting / using up resource it doesn't affect the others.
I think the critical thing is if they are all DBs that i run and manage i would consolidate, if they are not managed by me, it's easier to keep them separate.
There are currently 1 users browsing this thread. (0 members and 1 guests)