January 8, 2002 at 9:15 am
Hello All,
We have an issue here which was put to me in a meeting recently, and I am looking to this site for feedback on your views.
In our live environment, we have 1 production server and an application server. We are looking to make our prod. SQL Server a fault tolerent server. The application server will remain the same.
Our Application server has IIS to display ASP pages on an intranet and an in house developed Visual Basic application to control RF Hand Held Scanners. Both of these ASP & VB App read/update the SQL Server.
The consultants suggested, because of the necessity to keep the VB App running at all times, that it should be installed on the SQL Server, as we would have fault tolerance and hence, a more stable environment!
I really don't like this idea at all. Personally, I don't want any other software installed on the SQL Server. I'd rather keep the system as it is, and all applications that call the SQL Server are either on the Application server or Client PC's.
As I mentioned in the beginning, I am just after feedback on this topic.
Thanks,
Clive
January 8, 2002 at 9:32 am
My reflex is similar to yours, and in projects I've worked on before the webserver hosted the vb com+ dlls in mts, which meant that this layer was abstracted from the sql server. However, member servers, whether for files or applications often have more than one function, so this is not unheard of and I guess your question is "in what way could VB and SQL conflict when installed on the same machine". In my experience it is in:
(1) badly written VB programs may crash the machine, especially if they use the WIN api to manage memory.
(2) VB and SQL both use MDAC, so there may be a version conflict at some stage. As long as the VB program is compiled to use the same version it will be fine.
(3) VB and SQL may compete for resources - is your RAM and Processor up to the task?
(4) what additional libraries (COM components) does the VB app use? Are they thoroughly tested for memory leaks, compatibility etc?
If you can satisfy the above and police any changes to the VB program, I believe there is no reason why the two couldn't coexist.
Paul Ibison
Paul Ibison
Paul.Ibison@replicationanswers.com
January 8, 2002 at 10:38 am
Agree with Paul. I've done it, but usually only with shrink wrapped apps. They tend (not always) but tend to leak memory less simply because they recieve more testing.
I'd be wary. Instead, I'd suggest a cheap fallback server, perhaps even your test server (you should have one in addition to dev and prod) could be pressed in an emergency.
Steve Jones
January 8, 2002 at 11:32 am
I prefer production servers to be dedicated to SQL Server only. This way there is no conflict of resources and no question as to where a problem is if the SQL Server starts having memory problems. Our servers must be up 24 hours a day 7 days a week and we (the database department) don't need the added problem of wondering if our SQL Server is having problems because of some other application running on the same computer.
Robert Marda
Robert W. Marda
Billing and OSS Specialist - SQL Programmer
MCL Systems
January 8, 2002 at 12:29 pm
We try our best to keep SQL Server isolated from anything else, even in development. SQL Server will dynamically allocate and deallocate memory based on what else is going on. However, that takes time and resources. The other option is to statically assign the memory and while that works, it has its drawbacks.
The other thing you have to consider, as Paul has pointed out, is that the server running SQL Server is now vulnerable to anything the VB app may do wrong.
K. Brian Kelley
http://www.sqlservercentral.com/columnists/bkelley/
K. Brian Kelley
@kbriankelley
January 8, 2002 at 9:18 pm
I actually do this quite a bit with in house utility apps - things built to automate a process that was too awkward for SQL alone. Definitely have to exercise caution about how they are installed, written, used. Most of mine run once a day after hours. I don't care for 3rd party apps at all - one more thing to install, patch, worry about security holes, etc.
We also have some "heavier" processes that run on a desktop edition - really we're just using the agent as a super scheduler where the NT schedule is not robust enough and/or trying to write to the registry to do programmtic scheduling seems to be miserably hard.
If you're short hardware I dont think it's the worst thing you can do - just be careful!
Andy
January 9, 2002 at 3:13 am
Hello all,
Thanks for your input on this topic so far!
To answer a few points...
The VB app will is used between 10am and 8pm. If it's down, the warehouse cannot work and have to go back to pen and paper.
We do use additional Components withing the VB App. These are supplied by the RF Scanner vendors.
We do not use API calls for memory usage, so no problems there.
I'm still chewing over the idea of putting additional software on the server, even though I wrote the VB App myself (so hopefully it's stable!!)...As a few of you have said, it's nice to have a "clean" server just for the database.
Thanks again for your responses!
Clive
January 9, 2002 at 9:44 am
I agree the SQL box should remain SQL only. Fault tolerance is also a good idea. Nobody wants to go back to pen and paper! What are the minimum requirements for the IIS / VB application server? Could, say, a $500 PII 400 be made to work if the main server goes down?
January 9, 2002 at 10:13 am
API calls are not the only memory wasters. A VB app by iteself can cause issues. I'd tend to agree that the SQL box should remian standalone, though you might want a box that can handle either load (VB or SQL ) if one of the other boxes fails.
Steve Jones
Viewing 9 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic. Login to reply