Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
AskSQLTeam
Ask SQLTeam Question
0 Posts |
 Posted - 2007-01-29 : 07:26:46
|
| carlitos writes "I currently have MS SQL Server 2000 enterprise sitting on a pair of clustered MS servers 2003. I am running one business system on these servers 24x7 so uptime is extremely important.I have an inhouse RAD team who develop in Access and we are thinking of upsizing to SQL and adding their databases to the existing enterprise sql server (they have no expereince of this to date). The applications will be deployed using citrix connecting to the appropriate database. I am worried about putting my inhouse created databases along side a critical business database - should I be? (ie if i have a problem with one of the internally developed databases could there be a risk to the 24x7 business database?)" |
|
|
Michael Valentine Jones
Yak DBA Kernel (pronounced Colonel)
7020 Posts |
Posted - 2007-01-29 : 09:53:13
|
| I think the fact that you have people developing an application using software they have no experience with makes it unlikely that they will produce a trouble free application.I would encourage you to look a deploying this a a different server until the application has demonstrated trouble-free stability and good performance.CODO ERGO SUM |
 |
|
|
Kristen
Test
22859 Posts |
Posted - 2007-01-29 : 10:15:34
|
| We have separate environments for:Development(Users to understand that the server may go down for any reason, or may run slow etc. if a badly formed query is executed by mistake and takes 100% server CPU etc!)QASame hardware as live (or as close as Money/budget/etc. permit!)This is the QA done by the testing team (in-house for us), NOT the client (external for us)StagingThis is the client's own testing. We do this ON the production server - so that it is subjected to other activity on the Production Server and represents reasonably real-world performance.Some risk that the Staging Test will crash the Production databases, but [in our environment] this is deemed acceptable [too much cost for additional hardware for client; client does not have enough resources for a full-fledged QA program; etc] - so my justification may not be suitable for your environment! We do make the client aware of the business risk of this, none have yet considered the Risk unacceptable.Note that there is ALSO a risk that in "fiddling" with the Staging Database on the Production server we accidentally connect to the Production database and muck something up. A separate server would mitigate this risk. (We have User Admin Logins that have no permissions on Production databases; the admin users have enough permissions to elevate themselves to have Production Permissions (so when needed they Promote themselves) and an overnight task demotes them again. This helps mitigate accidentally doing something on a production databaseProductionSo finally once its Developed and Tested we roll the application (or the Next Great Version of the Application!!) out onto the Production server.Kristen |
|
|
|
|
|
|
Inhouse developed databases and SQL enterprise