Skip to main content

Where do old servers go to die?

We have a boat load of older servers. Dual core machines that used to run SQL Server in production. Newer technologies and demands on IT have required us to buy newer servers with quad and hex cores. So who says we have to retire these perfectly good dual core machines? Unfortunately Microsoft does. Licensing by the CPU means we can get quad and hex core licensing for the same price as dual core CPU's. With licensing being incredibly expensive at the enterprise level we cannot reasonably license these older servers and upgrade to newer technologies.
Here is a recent conversation I had with a Microsoft technology specialist on the idea of bundling together these older servers for cheaper licensing:
I have a question that someone at the SQL Saturday event said you would have some comment on even if the answer is basically no. I have a bunch of HP DL320's laying around with Dual Core processors. Now it is not economically sound to license these servers with enterprise SQL Server and yet they can still serve a purpose if it wasn't so darn expensive to license by CPU these older models. I was hoping the acquisition of Datallegro in 2008 would lead to more than just a competitive reach in data warehousing for Microsoft. I was hoping someone would see the value in allowing older servers to be bundled as one using something like Datallegro so that we could still use these servers in production. I would love to bundle up 4 of these servers and license as one server with 8 cores. So my question is very open here. What do you recommend other than buying new servers (which we have already done)? Can we use these older servers in production without killing ourselves on licensing? Has Microsoft considered this issue with older servers? What other solutions can you recommend? - Tony

Sorry, but the Parallel Data Warehouse solution we will be delivering later this year (and built from the DATAllegro technology) is a self-contain data warehouse appliance and doesn’t represent a change to our licensing model in terms of the ability to bundle otherwise stand-alone servers.

Most of our customers who have older hardware which cannot not be used for production purposes redeploy them for development and testing purposes where Developer Edition can be employed. Developer Edition is available for a nominal charge (if not already covered through existing agreements). Outside of the licensing concerns, older hardware is more prone to failure and replacement parts can be hard to come by. For this reason alone, we wouldn’t recommend using older systems in a production setting. - Microsoft rep


So here I am still wondering how I can make those servers useful.
Labels:

Comments

Post a Comment

Popular posts from this blog

Why fragmentation occurs and how to avoid/fix it.

Let's suppose you have this table: We have made last name the primary key in this table Now lets import some rows into the table and check the fragmentation Notice the fragmentation at 96.48% and all we did was one import of 16426 records. So now we have several questions: How bad is this? Fragmentation causes SQL Server to skip around to read data from your tables. For a one time read on a small table this is virtually meaningless. In a job that may need to read millions of records, this could tear apart your performance. Ok this is bad. How did it happen? The primary key on a table is clustered. This means the data will be stored according to the primary key. In our case, last name. When data doesn't come in the same way you store it (i.e. Customer names are not coming in alphabetically, but rather randomly) SQL Server must constantly split pages to store the data correctly. This causes data to be "fragmented" into multiple areas of the disk instead of one continuou...
Post a Comment
Read more

SQL Server ETL for Data Lineage

What is data lineage? Ok let us suppose you built a wonderful database with loads of data coming from source files from your vendors, your own AS400, and different departments of your own organization. All of this data has been imported into 200 tables in this database producing a plethera of information that is used for reporting purposes. One day a department head comes to you and says, "I think this number here on this report is wrong. Where did you get it from?" Do you escort that person to the computer room and show him/her your server? No, I didn't think so. So how do you come up with where the information came from? Likely you find a data load expert in your IT department and have him/her spend the next several minutes/hours/days rummaging through stored procedures, ssis packages, dts packages, custom applications, etc trying to find this information. However, if you had this: you could simply pull up the history of how that data came to be loaded and point. How us...
Post a Comment
Read more

DBA 101 - Connecting to an unresponsive SQL Server

I will attempt, over the course of many blogs, to tackle troubleshooting for a beginning to intermediate DBA. Troubleshooting is like an octopus with a hundred arms. There is no silver bullet but at least I can give you some tools for your belt to help determine the next steps in troubleshooting many common problems that you will see. So where do we begin? I don't know. Let's dive in and see where we end up. Problem - Nobody can connect to the SQL Server and it is not responding to any requests. Wow this seems like an impossible problem and is in reality two problems. Lets address the most critical problem which is you cannot even address why the SQL Server isn't responding to requests because nobody can connect to it to see what is going on. A weak solution - Often times an inexperienced DBA or what is often called an "accidental" DBA would pull the plug on the server, wait ten seconds, and then power it back on. Now this isn't the worst possible solution.....
2 comments
Read more