Windows 7 PC As a Database Server?

[Mike Derrick]

We've got a customer with an outdated Windows 2003 server on its last legs and they would like to install our 10.1C application database on a 64 bit Windows 7 Professional PC. It's got plenty of disk space, CPU and RAM. Also, they are currently running C/S but are going to upgrade to our Appserver version soon. My question is: can you use a PC as a database server? What are the pitfalls and gotchas?

Thanks!

 

[TomBascom]

Sure. You /can/.

First of all -- 10.1C? Ummm, it is long past time to move on. If you're putting a new system out there it should be at least 10.2B (service pack 6 or better). Or 11.1.

Why? Major performance benefits for one. A few hundreds or maybe even thousands of bug fixes for another.

As far as the Windows server part of things goes... Server 2008 would be the more rational thing to do. But there's nothing inherent with Windows 7 that will stop you. One of my development boxes is W7. It works. I'm sure it would be fine for a modestly sized system.

All of the server components should be 64 bits. Both the OS and Progress. The *only* piece that still needs to be 32 bits is the GUI client. Since this is a server that shouldn't be a problem.

 

[Mike Derrick]

Thanks Tom. 10.1C, yes yes yes... OE 11 is in-house but needs to be installed and tested.

So how about: Pitfalls and gotchas?

I assume I'll need to "Allow" prowin32 through Windows Firewall? Do I need to specify the db port ranges too? Do anything with the UAC? Is there any sort of checklist somewhere I can go through?

TIA!

 

[Rob Fitzpatrick]

If you try it you'll regret it; it's just a question of when. That's my $0.02.

For one thing, you can't run Enterprise RDBMS on a Windows client OS; only Personal or Workgroup. And if it's production (or even non-production at a client site), it should be Enterprise RDBMS unless the database is trivially small.

For another, if you are doing any file sharing (e.g. for users to access code or output from batch jobs), Windows client OSes have limits on concurrent share connections that servers OSes don't have. Also, by client OSes optimize for foreground performance (short scheduler quanta), though this is configurable. I'm sure there are other differences.

If you are set on re-purposing the hardware then do that if you must (understanding that you are relying on low-end commodity components), but don't re-purpose the OS. Client OSes are for clients.

 

[Mike Derrick]

If you try it you'll regret it; it's just a question of when.

We have, and we did/do.

But I was really wondering if it is a supported configuration too. We are telling them that we won't do it.

Thanks for the input guys.

 

[TomBascom]

...
For one thing, you can't run Enterprise RDBMS on a Windows client OS; only Personal or Workgroup.

Are you saying that it won't work or that there is some bizarre license restriction? (There's no limit of those -- I lost track a long time ago. I lost interest in keeping track too, it's obvious that the license terms are being written by someone who long ago lost touch with the real world.)

Because I'm pretty sure that it works. Someone whose name I forget has a couple up & running

Not that I think it's a /good/ idea. Just that it works.

 

[Rob Fitzpatrick]

I guess I was wrong. I read that "fact" recently, maybe in a KB article. Some of those are pretty out-of-date, so maybe the functional restriction of Enterprise on PC no longer exists. I can't say I've tried it; I like to have my DBs on Linux.

 

[Mike Derrick]

Reasons NOT to run a Windows 7 PC as a Database server?

How about a change in the direction of this thread?

Our app is pretty simple really. Installations are typically 1-5 users, it is not a real transaction intensive application or a 24/7 database, we deploy with the Workgroup database and have yet to reach the 2 GB limit on any of the extents (so the Enterprise DB is a moot point in our case), and our customers are extremely price point sensitive.

Some gotchas I encountered were: Dynamic IP Addresses (we can't use -S < IPAddress > to connect reliably), Windows Firewall, Anti-virus software, folder permissions, and UAC settings to name a few.

So, when the customer asks "why not", and their hired out IT guy does enough research (perhaps but not likely) to see that in CAN be done, and I need to return an email to the office manager telling her WHY we won't install on a PC ( which just came in), I'd like to be able to lay out the issues succinctly and simply.

So... what are your TOP 3 REASONS NOT TO RUN A PC AS A DATABASE SERVER? (Brevity and simplicity appreciated!)

 

[Rob Fitzpatrick]

Re: Reasons NOT to run a Windows 7 PC as a Database server?

Capabilities:
Enterprise RDBMS isn't just about large file support. It is also much more tunable for performance. However given what you've said about the application and pricing, that may not be a compelling advantage.

Hardware:
PC OEMs are also extremely price-sensitive, and their margins are thin. So they use parts that are cheaper and less reliable than server hardware. Also, given their intended use they have little or no fault-tolerance capability, e.g. redundant power supplies, RAID controllers, error-correcting RAM, etc. Similarly, the disks and disk controllers you get in PCs are not as reliable as those in servers. Even if your application doesn't write a lot of information, or have high TPS, you still want the data to be correct and corruption-free. And even if the application doesn't have to run 24/7, it does need to run when the business runs. If the smoke gets out of the power supply or the hard drive decides one day not to let you boot, the client will have downtime and will not be happy. Cheap hardware is a false economy.

OS:
Features like directory permissions and firewalls exist in all OSes, so that isn't a knock against Windows per se. As with any OS, you do need someone who is knowledgeable enough to configure it properly. However the need for anti-virus software and frequent reboots for system updates is a knock against Windows. Client versions in particular, which are more feature-rich, also have the biggest attack surface for malware.
Windows may use DHCP by default, but that is configurable. You can use static IP addresses if you wish, but as I said earlier understand that networking in Windows Server vs. Windows clients is not identical.

Three reasons:
1. PCs are made with commodity consumer-grade parts that are designed primarily for low price, not reliability. They have relatively high rates of failure. Failure, at best, is downtime and temporary business impact. Failure, at worst, is data corruption or data loss and sustained business impact. Databases are tested most and work best with server hardware.
2. All OSes require maintenance, but Windows requires more. That translates to higher cost of ownership. Also, Windows is much more susceptible to malware attack.
3. Client OSes are for client workloads. Period.

I would suggest a low-end server with a couple of disks in RAID 1. If you want to save money on OS licensing, install CentOS. And figure out a reasonable backup plan with the client. Cheap hardware and code aren't worth a damn if they lose their data.

 

[TomBascom]

Re: Reasons NOT to run a Windows 7 PC as a Database server?

As Rob says -- saving a few bucks on the hardware is a false economy. One which many people pursue anyway. It keeps consultants in business

They will probably get away with it. But if they are one of the unlucky ones who doesn't get away with it you will be very, very sorry. Nobody ever wants to admit that it was their own short-sighted decision that led to the problem. So be ready to have lots of blame heaped on your worthless and unreliable application and the rinky-dink database that you deployed it on. Because that's the way that cookie pretty much always crumbles.

 

[TomBascom]

Your number one line of defense in situations like this is after-imaging.

Make sure that you implement after-imaging and that it is always working. Test a restore and roll-forward every now and again. If you are lucky you will never need it (not that anyone will thank you). If you are unlucky you will be very, very glad that you have it in place and know exactly how to use it.

 

[Mike Derrick]

Here's my go at it. Comments, corrections, etc. all welcome.

1. In general, servers, including their hardware and systems are designed to be more robust and reliable and scalable. (i.e More disk storage, faster disk access, and built-in redundancy.)
2. The PC must have a static IP address. Most PCs are set up with dynamic IP addresses. Servers have static addresses for a reason. If the IP changes on the PC, it causes major issues.
3. Microsoft desktop operating systems have a limit of 10 concurrent connections.
4. Server operating systems are designed for multi-user environments even for things like support. A PC doesn't support multiple sessions. If you want to use Remote Desktop for example, you can do that to a server and it creates a separate session for you. On a desktop operating system, when you RDP, it kicks the local user off.
5. Backups may or may not be a reason depending on what backup strategy you use, but many best-in-class backup solutions are meant to run on server environments.
6. Server operating systems support use of more memory. You are limited to the amount of memory that a desktop operating system can utilize. You can put it in, but the system will not use it. The max amount is dependent on the exact specification of the PC, 64 bit or 32 bit, etc...

I would like to have a pat email response to send out next time a customer starts down this route. I'm going to re-read, review, and revamp this list to make sure your points are well represented.

Thanks again guys!

 

[RealHeavyDude]

IMHO - the less purposed a system is the more maintenance and support it will need to keep it running smoothly. I can not imagine a lesser purposed system for running mulit-user databases of any vendor in a productive environment than a PC running a Window client OS.

Heavy Regards, RealHeavyDude.