Post reply

Reducing cores on EE to reduce licencing costs

  • July 19, 2012 at 3:10 am

    #276074

    We have a SQL 2008R2 Enterprise Edition 64-bit 128GB RAM (on Windows server 2008R2) with 2 processors, each with 6 cores, each with Hyperthreading

    We believe the CPU on our server is not stressed at all, so to reduce licence cost, we want to reduce the number of cores whilst still keeping acceptable performance for our users.

    The 'processor' page on the SQL server properties shows

    •NumaNode0

    oCPU0

    oCPU1 and so on to CPU11

    •NumaNode1

    oCPU12

    oCPU13 and so on to CPU23

    At the moment the automatic affinity for processors is set for both processor and I/O

    Due to the new licencing costs of per core and the fact the our server only uses around 20% CPU most of the time (according to perfmon), the easiest option we think is to disable NumaNode1 thereby halving the cost of the licence whilst hopefully still prodiving sufficient performance for the users.

    Is this the best way rather then selecting specific CPUx from NumaNode0 and NumaNode1 or is selecting entries from NumadNode0 and NumaNode1 to get to the same end count of cores better for performance?

    If using entries from both NumaNodes is better for performance, are CPU0 and CPU1 for core 1 with Hyperthreading or is it CPU0 and CPU6 for core 1 then CPU1 and CPU7 for core 2 etc.

    Can anyone provide information on the best/recommend approach for reducing our core count and also is the UI for this 'reliable' rather than using sp_configure?

    Thanks in advance.

  • July 19, 2012 at 3:37 am

    #1514705

    I looked into this a few months ago, and I remember I found that you can't reduce licensing costs this way.

    Will try and find some more info for you to confirm.

    Sorry :pinch:

    Edit: By "this way" I mean setting processor affinities in the SQL Server config, either by sp_configure or GUI.

    Disabling CPU's at the hardware level would probably be ok.

  • July 19, 2012 at 3:39 am

    #1514707

    The only way would be to disable the second processor in the BIOS or remove the processor from the server.

    Changing affinity settings doesnt allow you to reduce the number of licenses you require.

    If Windows can see it, SQL can see it and MS say if SQL can see it, it needs to be licensed.

  • July 19, 2012 at 3:48 am

    #1514712

    Thanks for the replies we will look at the possibility of removing one processor, one of our next options failing that then would be to 'downgrade' to Standard Edition, is that 'supported' via the SQL Install upgrade install route?

    Thanks.

  • July 19, 2012 at 3:50 am

    #1514713

    I would do that as a side by side upgrade, but check that you are not using any enterprise only features first

    SELECT feature_name, feature_id

    FROM sys.dm_db_persisted_sku_features

    ORDER BY feature_name;

    If you are you will need to stop using these features and code around them to make it work with Standard edition.

  • July 19, 2012 at 3:57 am

    #1514719

    We are only using fuzzy lookup in an SSIS package which we could move to a new group server dedicated for BI. As our current server has 128GB RAM It is a shame that Standard is limited to 64GB.

    By side-by-side do you mean a new instance and then backup/restore all the db's?

    This will cause problems with instance name/connections which can of course be worked out and of course safety is important 🙂

  • July 19, 2012 at 4:03 am

    #1514721

    Side by side, by either

    1. A new server with the same instance name, then follow the steps on how to rename the host of a sql server to change it to the originial server so you dont have to change connection strings

    2. New instance same server change your connection strings

    In Place

    Uninstall 2008 then install 2012 if you want the same instance name

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply