Estimating Data Compression Savings in SQL Server 2012

SQL Server Data Compression (which was first introduced in SQL Server 2008, and is an Enterprise Edition only feature) lets you compress individual indexes with either ROW or PAGE compression. It can be a huge win for many SQL Server workloads, by letting you reduce both your required disk I/O and your memory usage at the cost of some added CPU usage in some scenarios.

By design, there is no “Compress Entire Database” command in SQL Server 2012. Instead, you need to evaluate individual indexes, based on their size, estimated compression savings and volatility. The ideal case is a large table that shows very good compression savings that is read-only. A bad candidate is a small table, that does not show much compression savings, with very volatile data.

I long ago got tired of manually running the sp_estimate_data_compression_savings system stored procedure with hard-coded parameters for each index in a database, so I decided to write some T-SQL that would somewhat automate the process.  If you set the schema name, table name, and desired data compression type in the variable declarations at the top of the script, you will get some pretty detailed information about all of the indexes in that table.

You should run the entire query at once, after you have supplied your own values. It may take some time to run, depending on your hardware and on how large your tables are.  You could also wrap part of this in a stored procedure that you could call for each table in a database, and have it write the results out to a table that you could easily query later.


    -- SQL Server 2008, 2008 R2 and 2012 Data Compression Estimation Queries
    -- This may take some time to run, depending on your hardware infrastructure and table size
    -- Glenn Berry 
    -- April 2013
    -- http://www.sqlskills.com/blogs/glenn/
    -- http://glennberrysqlperformance.spaces.live.com/
    -- Twitter: GlennAlanBerry
 
    -- Get estimated data compression savings and other index info for every index in the specified table
    SET NOCOUNT ON;
    DECLARE @SchemaName sysname = N'dbo';                                -- Specify schema name
    DECLARE @TableName sysname = N'ActivityEvent';                        -- Specify table name
    DECLARE @FullName sysname = @SchemaName + '.' + @TableName;
    DECLARE @IndexID int = 1;
    DECLARE @CompressionType nvarchar(60) = N'PAGE';                    -- Specify desired data compression type (PAGE, ROW, or NONE)
    SET @FullName = @SchemaName + '.' + @TableName;
 
    -- Get Table name, row count, and compression status for clustered index or heap table
    SELECT OBJECT_NAME(object_id) AS [Object Name], 
    SUM(Rows) AS [RowCount], data_compression_desc AS [Compression Type]
    FROM sys.partitions WITH (NOLOCK)
    WHERE index_id < 2
    AND OBJECT_NAME(object_id) = @TableName
    GROUP BY object_id, data_compression_desc
    ORDER BY SUM(Rows) DESC;
 
    -- Breaks down buffers used by current table in this database by object (table, index) in the buffer pool
    -- Shows you which indexes are taking the most space in the buffer cache, so they might be possible candidates for data compression
    SELECT OBJECT_NAME(p.[object_id]) AS [Object Name],
    p.index_id, COUNT(*)/128 AS [Buffer size(MB)],  COUNT(*) AS [Buffer Count], 
    p.data_compression_desc AS [Compression Type]
    FROM sys.allocation_units AS a WITH (NOLOCK)
    INNER JOIN sys.dm_os_buffer_descriptors AS b WITH (NOLOCK)
    ON a.allocation_unit_id = b.allocation_unit_id
    INNER JOIN sys.partitions AS p WITH (NOLOCK)
    ON a.container_id = p.hobt_id
    WHERE b.database_id = DB_ID()
    AND OBJECT_NAME(p.[object_id]) = @TableName
    AND p.[object_id] > 100
    GROUP BY p.[object_id], p.index_id, p.data_compression_desc
    ORDER BY [Buffer Count] DESC;

 
    -- Get the current and estimated size for every index in specified table
    DECLARE curIndexID CURSOR FAST_FORWARD
    FOR
        -- Get list of index IDs for this table
        SELECT i.index_id
        FROM sys.indexes AS i WITH (NOLOCK)
        INNER JOIN sys.tables AS t WITH (NOLOCK)
        ON i.[object_id] = t.[object_id]
        WHERE t.type_desc = N'USER_TABLE'
        AND OBJECT_NAME(t.[object_id]) = @TableName
        ORDER BY i.index_id;
 
    OPEN curIndexID;
 
    FETCH NEXT FROM curIndexID INTO @IndexID;
 
    -- Loop through every index in the table and run sp_estimate_data_compression_savings
    WHILE @@FETCH_STATUS = 0
        BEGIN
            -- Get current and estimated size for specified index with specified compression type
            EXEC sp_estimate_data_compression_savings @SchemaName, @TableName, @IndexID, NULL, @CompressionType;
 
            FETCH NEXT
            FROM curIndexID
            INTO @IndexID;
        END
    CLOSE curIndexID;
    DEALLOCATE curIndexID;

    -- Index Read/Write stats for this table
    SELECT OBJECT_NAME(s.[object_id]) AS [TableName],
    i.name AS [IndexName], i.index_id,
    SUM(user_seeks) AS [User Seeks], SUM(user_scans) AS [User Scans],
    SUM(user_lookups)AS [User Lookups],
    SUM(user_seeks + user_scans + user_lookups)AS [Total Reads],
    SUM(user_updates) AS [Total Writes]     
    FROM sys.dm_db_index_usage_stats AS s WITH (NOLOCK)
    INNER JOIN sys.indexes AS i WITH (NOLOCK)
    ON s.[object_id] = i.[object_id]
    AND i.index_id = s.index_id
    WHERE OBJECTPROPERTY(s.[object_id],'IsUserTable') = 1
    AND s.database_id = DB_ID()
    AND OBJECT_NAME(s.[object_id]) = @TableName
    GROUP BY OBJECT_NAME(s.[object_id]), i.name, i.index_id
    ORDER BY [Total Writes] DESC, [Total Reads] DESC;

    -- Get basic index information (does not include filtered indexes or included columns)
    EXEC sp_helpindex @FullName;

    -- Individual File Sizes and space available for current database  
    SELECT f.name AS [File Name] , f.physical_name AS [Physical Name],
    CAST((f.size/128.0) AS decimal(15,2)) AS [Total Size in MB],
    CAST(f.size/128.0 - CAST(FILEPROPERTY(f.name, 'SpaceUsed') AS int)/128.0 AS decimal(15,2))
    AS [Available Space In MB], [file_id], fg.name AS [Filegroup Name]
    FROM sys.database_files AS f WITH (NOLOCK)
    LEFT OUTER JOIN sys.data_spaces AS fg WITH (NOLOCK) 
    ON f.data_space_id = fg.data_space_id OPTION (RECOMPILE);

A SQL Server Hardware Tidbit a Day – Day 11

For Day 11 of this series, I am going to talk about some of the basic things that you should consider from a hardware perspective when you are trying to increase the basic resiliency and availability of an individual database server. These are some of the first steps you would take as part of designing a high availability solution for your data tier.

The basic principal here is to try to eliminate as many single points of failure as possible at the hardware and configuration level. I believe you should do these things regardless of what other high availability techniques you decide to use. When you are choosing components for a database server (as opposed to a web server, for example), here are some basic things to include:

  1. Two internal drives in a RAID 1 configuration for the operating system and SQL Server binaries. These drives should be using the embedded hardware RAID controller that is available on most new rack mounted servers. I try to get at least 146GB, 15K 2.5” drives for this purpose. Using 15K drives will help Windows Server boot a little faster, and will help SQL Server load a little faster when the service first starts up. Using 146GB (or larger) drives will give you more room to accommodate things like SQL Server error log files, dump files, etc., without being worried about drive space. Another increasingly viable alternative is to use two of the newer, entry-level data center SSDs, such as the 200GB Intel DC S3700 in a RAID 1 configuration to get even better performance and reliability for your system drive.
  2. Use dual power supplies for the server, each plugged into separate circuits in your server room or data center. The server should also be plugged into an Uninterruptable Power Supply (UPS) on each circuit, and ideally have a backup power source, such as a diesel generator for your data center. The idea here is to protect against an internal power supply failure , a cord being kicked out of a plug, a circuit breaker tripping, or loss of electrical power from the utility grid.
  3. You should have multiple network ports in the server, with Ethernet connections into at least two different network switches. These network switches should be plugged into different electrical circuits in your data center. Most new rack mounted servers have at least four gigabit Ethernet ports embedded on the motherboard.
  4. You should have multiple RAID controller cards (if you are using Direct Attached Storage), multiple Host Bus Adapters (HBAs) if you are using a fiber channel SAN, or multiple PCI-e Gigabit (or better) Ethernet cards with an iSCSI SAN. This will give you better redundancy and better throughput, depending on your configuration.
  5. Wherever your SQL Server data files, log files, tempdb files, and SQL Server backup files are located, they should be protected by an appropriate RAID level, depending on your budget and performance needs. We want to keep our databases from going down due to the loss of a single drive. One thing to keep in mind, is that RAID is not a substitute for an appropriate SQL Server backup and restore strategy!  Never, never, never let anyone, whether it is a SAN vendor, a server admin from your Operations team, or your boss, talk you into not doing SQL Server backups as appropriate for your Recovery Point Objective (RPO) and Recovery Time Objective (RTO) metrics.  I cannot emphasize this point enough!  There is absolutely no substitute for having viable SQL Server backup files.

Despite this fact, you will undoubtedly be pressured multiple times in your career, by different people, into not running SQL Server database backups for one reason or another. You really need to stand your ground and not give in to this pressure. There is an old saying: “If you don’t have backups, you don’t have a database”.

I also want to note one configuration setting I like to use for database servers, to reduce their boot and SQL Server startup time. For a standalone database server, reducing your total reboot time has a direct effect on your high availability numbers. I always go into the BIOS setup for the server, and disable the memory testing that normally occurs during the POST sequence.

This will shave a significant amount of time off of the POST sequence (often many minutes), so the server will boot faster. I think this is pretty low risk, since this testing only occurs during the POST sequence. It has nothing to do with detecting a memory problem while the server is running later (which is the job of your hardware monitoring software). I am sure some people may disagree with this setting, so I would love to hear your opinions.

A SQL Server Hardware Tidbit a Day – Day 10

For Day 10 of this series, I am going to talk a little bit about disk performance and one easy benchmark tool that you can use to quickly compare the performance of different types of disks and disk arrays. CrystalDiskMark, which is available from Crystal Dew World is a fairly well-known disk subsystem benchmark. You can select the number of test runs, desired file size, desired test file type, and which logical drive you want to test.  It allows you to measure:

  1. Sequential read and write performance in megabytes/second
  2. Random read and write performance for a 512K block size
  3. Random read and write performance for a 4K block size
  4. Random read and write performance for a 4K block size with a queue depth of 32

There are other disk benchmarks such as SQLIO that will do a much more thorough job of benchmarking your disk subsystem, but they are a little more difficult to work with. Using CrystalDiskMark should be a supplement to other disk benchmarking that you do. I like to do my first round of testing on each logical drive using CrystalDiskMark before I do more detailed, time-consuming testing with SQLIO. You should test all of your logical drives with these tools before you install SQL Server.

I have captured the test results for a high-performance consumer grade 6Gbps MLC SSD (the 256GBGB Samsung 840 Pro) in Figure 1, showing pretty impressive sequential and random I/O performance. This particular drive is basically limited by the sequential bandwidth limits of the 6Gbps SATA III interface (which is about 550MB/sec). We will probably start to see 12Gbps SATA become available over the next year or so.

Figure 2 shows the results for two 15K SAS drives in a RAID 1 array. Both sequential and random read write performance are much better with the single SSD drive, but where you see the biggest difference is with random reads and writes with a queue depth of 32, which is more like most server workloads. That is where flash-based storage really shines.

image thumb8 A SQL Server Hardware Tidbit a Day – Day 10

Figure 1: CrystalDiskMark Results for a 256GB Samsung 840 Pro

 

image thumb9 A SQL Server Hardware Tidbit a Day – Day 10

Figure 2: CrystalDiskMark Results for two 300GB 15K SAS drives in RAID 1

Figure 3 shows the test results for an older 640GB Fusion-io Duo MLC device, which has better sequential read performance than the Samsung 840 Pro (since it is plugged into a PCI-E slot), but actually has lower random I/O performance at high queue depths with this test. Keep in mind that consumer level SSDs do not perform as well when they are under a server-level workload, and their performance becomes more inconsistent as they have to do more garbage collection as part of their wear-leveling process.

image thumb10 A SQL Server Hardware Tidbit a Day – Day 10

Figure 3: CrystalDiskMark Results for a 640GB Fusion-io Duo MLC device

Figure 4 shows the test results for an LSI Nytro WarpDrive BLP4-1600 card using random data (which simulates the effect of data compression or backup compression). The LSI Nytro WarpDrive BLP4-1600 card uses hardware-based compression to improve write performance and increase its write durability. Hardware compression does not work as well when the data has already been compressed by any sort of software compression.

image thumb11 A SQL Server Hardware Tidbit a Day – Day 10

Figure 4: CrystalDiskMark Results for an LSI Nytro WarpDrive BLP4-1600 with random data

 

Figure 5 shows the test results for an LSI Nytro WarpDrive BLP4-1600 card using 0Fill data (which is highly compressible). The LSI Nytro WarpDrive BLP4-1600 card has much better write performance when the data is not already compressed. This is really a pretty impressive card.

image thumb12 A SQL Server Hardware Tidbit a Day – Day 10

Figure 5: CrystalDiskMark Results for an LSI Nytro WarpDrive BLP4-1600 with compressible data

One thing to keep in mind is that most consumer SSD drives perform better in their larger capacities (so a 256GB drive will have better performance than a 128GB drive of the same model line). You also want to make sure that you use a 6Gbps SATA III port for a 6Gbps SATA III SSD, or else you won’t get get all of the sequential performance the SSD drive is capable of. It you plug a 6Gbps SSD into an older 3Gbps SATA port, you will be limited to about 275MB/sec of sequential throughput.

Sequential throughput is very important when it comes to doing many common database-related tasks, such as backups and restores, creating indexes, and rebuilding indexes.

A SQL Server Hardware Tidbit a Day – Day 9

For Day 9 of this series, I want to talk about processor cache size and its relationship to SQL Server 2012 performance.

Cache Size and the Importance of the L2 and L3 Caches

All Intel-compatible CPUs have multiple levels of cache. The Level 1 (L1) cache has the lowest latency (i.e. the shortest delays associated with accessing the data), but the least amount of storage space, while the Level 2 (L2) cache has higher latency, but is significantly larger than the L1 cache. Finally, the Level 3 (L3) cache has the highest latency, but is even larger than the L2 cache. In many cases, the L3 cache is shared among multiple processor cores. In older processors, the L3 cache was sometimes external to the processor itself, located on the motherboard.

Whenever a processor has to execute instructions or process data, it searches for the data that it needs to complete the request in the following order:

1. internal registers on the CPU
2. L1 cache (which could contain instructions or data)
3. L2 cache
4. L3 cache
5. main memory (RAM) on the server
6. any cache that may exist in the disk subsystem
7. actual disk subsystem

The further the processor has to follow this data retrieval hierarchy, the longer it takes to satisfy the request, which is one reason why cache sizes on processors have gotten much larger in recent years.  Table 1 shows the typical size and latency ranges for these main levels in the hierarchy.

L1 Cache L2 Cache L3 Cache Main Memory Disk
32K size 256K size 20MB size 256GB size Terabyte size
2ns latency 4ns latency 6ns latency 50ns latency 15ms latency

Table 1: Data Retrieval Hierarchy for a Modern System

For example, on a new server using a 22nm Intel Ivy Bridge processor, you might see an L1 cache latency of around 2 nanoseconds (ns), L2 cache latency of 4 ns, L3 cache latency of 6 ns, and main memory latency of 50 ns. When using traditional magnetic hard drives, going out to the disk subsystem will have an average latency measured in milliseconds. A flash based storage product (like a Fusion-io card) would have an average latency of around 25 microseconds. A nanosecond is a billionth of a second; a microsecond is a millionth of a second, while a millisecond is a thousandth of a second. Hopefully, this makes it obvious why it is so important for system performance that the data is located as short a distance down this retrieval chain as possible.

The performance of SQL Server, like most other relational database engines, has a huge dependency on the size of the L2 and L3 caches. Most processor families will offer processor models with a range of different L2 and L3 cache sizes, with the cheaper processors having smaller caches and, where possible, I advise you to favor processors with larger L2 and L3 caches. Given the business importance of many SQL Server workloads, economizing on the L2 and L3 cache size is not usually a good choice. Figure 1 shows information about the caches in an Intel Xeon E5-2670 processor in the bottom right corner.

image thumb7 A SQL Server Hardware Tidbit a Day – Day 9

Figure 1: CPU-Z Showing Cache Size Information

If the hardware budget limit for your database server dictates some form of compromise, then I suggest you opt to initially economize on RAM in order to get the processor(s) you really want. My experience as a DBA suggests that it’s often easier to get approval for additional RAM, at a later date, than it is to get approval to upgrade a processor. Most of the time, you will be “stuck” with the original processor(s) for the life of the database server, so it makes sense to get the one you need when you first buy the server.

You do have to be keenly aware of your total physical core counts as you select a processor for SQL Server 2012 Enterprise Edition, since you will have to pay for each core license.

A SQL Server Hardware Tidbit a Day – Day 8

For Day 8 of this series, I want to talk a little bit about the various hardware license limits that are present in SQL Server 2012. These limits vary based on what edition of SQL Server 2012 you will be using, and what operating system you will be using. You need to keep these limits in mind as you are selecting and configuring your hardware.

Table 1 shows the RAM limits by Edition for different uses when you are running on Windows Server 2008 R2 SP1.

SQL Server 2012 Edition Database Engine RAM Limit Analysis Services RAM Limit
Standard Edition 64GB 64GB
Business Intelligence Edition 64GB 2TB on Windows Server 2008 R2 SP1
Enterprise Edition 2TB on Windows Server 2008 R2 SP1 2TB on Windows Server 2008 R2 SP1

Table 1: RAM Limits for SQL Server 2012 on Windows Server 2008 R2 SP1

Table 2 shows the higher maximum RAM limits when you are running on Windows Server 2012.

SQL Server 2012 Edition Database Engine RAM Limit Analysis Services RAM Limit
Standard Edition 64GB 64GB
Business Intelligence Edition 64GB 4TB on Windows Server 2012
Enterprise Edition 4TB on Windows Server 2012 4TB on Windows Server 2012

Table 2: RAM Limits for SQL Server 2012 on Windows Server 2012

Believe it or not, current server hardware is already getting close to these hardware license limits for RAM. If you are willing to pay the extra money for 32GB DDR3 RDIMMs, you can get 2TB of RAM in a four-socket server, and 4TB of RAM in an eight-socket server. The prices for 32GB DDR3 RDIMMs are finally starting to decrease (although they are still much more expensive than 16GB DDR3 RDIMMs), going from about $52/GB down to about $39/GB in the last couple of months. The smaller 16GB DDR3 RDIMMs are still much less expensive, at about $12/GB.

When the upcoming 15-core, Intel E7-4800 v2 and Intel E7-8800 v2 (Ivy Bridge-EX) processors are released in Q4 of 2013, you will be able to get 6TB of RAM in a four-socket server and 12TB of RAM in an eight-socket server. I would not be surprised to to see Microsoft raise the OS RAM limit on Windows Server 2012 when that happens, perhaps when Windows Server 2012 SP1 is released. (Note: I updated this information based on information announced at IDF2013).

SQL Server 2012 Standard Edition still has a RAM limit of 64GB. This low limit may catch many people by surprise, since it is very easy to have much more than 64GB of RAM, even in a two-socket server. You should keep this RAM limit in mind if you are buying a new server and you know that you will be using Standard Edition. One possible workaround for this limit would be to have a second or third instance of SQL Server 2012 Standard Edition installed on the same machine, so you could use more than the 64GB limit for a single instance. The physical socket limit for SQL Server 2012 Standard Edition is still four processor sockets or sixteen logical cores, whichever is lower.

As far as the limits for total logical cores are concerned, you can go all they way up to 640 logical cores with SQL Server 2012 Enterprise Edition running on Windows Server 2012 Standard Edition, while you can only go up to 256 logical cores on Windows Server 2008 R2 SP1 Enterprise Edition. This is less of a problem with current hardware. An eight-socket server with Intel Xeon E7-8870 processors would only have 160 logical cores, while an eight-socket server with upcoming Intel Xeon E7 88xx v2 processors would have 240 logical cores.

Make sure to remember these license limits if you are buying a new server that will be running SQL Server 2012 (or if you are upgrading to SQL Server 2012 on a large existing server, because they are different than they were on SQL Server 2008).

A SQL Server Hardware Tidbit a Day – Day 7

For Day 7, I want to talk about one specific Intel processor series that I highly recommend that you do not use for SQL Server 2012 workloads. This processor is the 45nm Intel Xeon 7400 Series, which was released in Q3 of 2008. There were seven specific models in this series, based on the Penryn Core2 microarchitecture, culminating in the Intel Xeon X7460 processor.

At the time of it’s initial release, this was a very good processor. It has a base clock speed of 2.66GHz, with six physical cores, which allowed you to have 24 physical cores in a four-socket server (such as a Dell PowerEdge R900), along with up to 256GB of RAM. This sounds impressive, but there are some fundamental issues with this processor by modern standards.

I can remember unsuccessfully begging my CTO at NewsGator to let me buy one of these during the late-2008 to mid-2009 time-frame. That was one battle I lost (which was actually a good thing in hindsight), but I was later able to get something much better.

The Intel Xeon 7400 series was the last four-socket capable Intel processor to use the older symmetric multiprocessing (SMP) architecture instead of the more modern non-uniform memory access (NUMA) architecture. This means that it is hobbled by the limitations of the old front-side bus, where all of the processors in a system use the same shared pathway to main memory. This causes increasing contention and performance bottlenecks as the number processors in a system increases.

The Xeon 7400 series has a relatively high number of physical cores that have fairly low single-threaded performance by modern standards. It also does not have Intel hyper-threading or Turbo Boost technology. This means that it is fairly expensive to purchase licenses for SQL Server 2012 Enterprise Edition, for a system that will have poor performance compared to a brand new system.

Here is an example from the TPC-E OLTP benchmark. There was a Dell R900 system with four Xeon X7460 processors with a TPC-E score of 671.35. Dividing that score by 24 physical cores gives us a result of 27.97 per core. There is a new HP Proliant DL380p Gen 8 system with two Xeon E5-2690 processors with a TPC-E score of 1881.76. Dividing that score by 16 physical cores gives us a result of 117.61 per core, which is 4.2 times higher than the old system.

The old system would require (24) SQL Server 2012 Enterprise Edition core licenses, which have a retail cost of $6872.00 each. That would be $164,928.00 for the licenses required for the entire system. The new system would require only (16) SQL Server 2012 Enterprise Edition core licenses, which would cost $109,952.00 for the entire system.

Reusing that old server for SQL Server 2012 would cost 50% more, to get about 1/4th of the OLTP performance. That seems like a pretty bad choice to me. Many organizations still have systems running with that processor, since it is not really that old yet. When it becomes time to upgrade to SQL Server 2012, do not make the mistake of reusing your existing hardware. You will get much lower performance and scalability, and potentially pay much higher SQL Server licensing costs.

A SQL Server Hardware Tidbit a Day – Day 6

For Day 6 of this series, I am going to talk about Geekbench. Geekbench is a cross-platform, synthetic benchmark tool from Primate Labs. It provides a comprehensive set of benchmarks designed to quickly and accurately measure processor and memory performance. There are 32-bit and 64-bit versions of Geekbench, but in tryout mode you can only use the 32-bit version. A license for the Windows version is only $12.99, so it is quite affordable. The latest version is 2.4.2, which was released on March 7, 2013. The release history for Geekbench is here.

One nice thing about Geekbench is that there are absolutely no configuration options. All you have to do is just install it and run it, and within two to three minutes you will have an overall benchmark score for your system, which is further broken down into four sections, two measuring processor performance, Integer (12 scores) and Floating Point (14 scores), and two measuring memory bandwidth performance, Memory (5 scores), and Stream (8 scores).

I tend to focus first on the overall Geekbench score, and then look at the top level scores for each section, as shown in Figure 1. These scores can be used to measure and compare the absolute processor and memory performance between multiple systems, or between different configurations on the same system.

image thumb6 A SQL Server Hardware Tidbit a Day – Day 6

Figure 1: Geekbench Result and System Information

I always run each test at least three times in succession, and take the average overall Geekbench score. In just a few minutes, gives me a pretty good idea of the overall processor and memory performance of the system.

You can also use Geekbench to validate that you are getting the best possible memory performance from your system, by looking at the memory and stream scores. Depending on the processor (and it’s memory controller) that is in your system, you can get different memory bandwidth and performance depending on what type of RAM modules are installed in which memory sockets in your server.

To get the best performance on Geekbench (and in real-life database usage), it is very important that you make sure that Windows is using the High Performance Power Plan instead of the default Balanced Power Plan (with Windows Server 2008 or newer). On most new server systems, there are also Power Management settings in the main system BIOS that need to be set correctly to get the best performance from a system. Otherwise, the system will try to minimize electrical power usage (at the cost of performance) despite what your Windows power plan setting is trying to do. Generally speaking, you either want to disable power saving at the BIOS level or set it to OS control (so that you can dynamically control it from within Windows). 

I like to run Geekbench on every available non-production system that I have access to, so that I can save the various system configurations and Geekbench score results in a spreadsheet. Then, I can use this information to roughly compare the overall CPU/memory “horsepower” of different server systems. This is very useful if you are doing capacity or consolidation planning.

For example, let’s say that you have an existing database server with (4) six-core 2.66GHz Intel Xeon X7460 processors and 128GB of RAM, and this system has an averaged Geekbench score of 16,632. You are assessing a new system that has (2) eight-core 2.9GHz Intel Xeon E5-2690 processors and 192GB of RAM, and the new system has an averaged Geekbench score of 28,964. In this situation, you could feel extremely confident from a CPU and RAM perspective that the new, two-socket system could handle the workload of the old four-socket system, with plenty of room to spare. You could use the extra CPU capacity of the new system to handle additional workload, or you could use it to reduce your I/O requirements by being more aggressive with SQL Server data compression and backup compression.

In the absence of a large number of different systems on which to run Geekbench, you can still browse online the published Geekbench results for various systems. Simply look up the results for the system closest in spec to the one being evaluated. You can use the search function on that page to find systems with a particular processor, and then drill into the results to get a better idea of its relevance.

Whenever you are comparing Geekbench scores between different systems, make sure you are comparing 32-bit scores to 32-bit scores, and 64-bit scores to 64-bit scores, since the 64-bit version of Geekbench will give you significantly higher score on most newer processors.

A SQL Server Hardware Tidbit a Day – Day 5

For Day 5 of this series, I will talk about the incredibly useful CPU-Z utility, which is available for free from cpuid.com. The latest release of the tool is version 1.63, which came out on February 8, 2013. I always download and use the 64-bit, English, no install zip version of the tool. The release notes and version history are here.

This tool will give you a great amount of detail about your processor(s), caches, motherboard, and memory, among other things. The CPU tab is shown in Figure 1.

image thumb1 A SQL Server Hardware Tidbit a Day – Day 5

Figure 1: CPU tab of CPU-Z 1.63

For example, Figure 1 shows that I have a 32nm, Intel Xeon E5-2670 (Sandy Bridge-EP), that has a rated base clock speed of 2.60GHz, but it is actually running at 2.95GHz. This shows that the processor is running at full speed, with Turbo Boost increasing the speed to 2.95Ghz (at least on Core 0 of Processor #1). It is possible, and actually quite common for people to see that their processor is running at a much lower speed than its rated based clock speed, due to either the current Windows Power Plan that is in use on the operating system, or because of the hardware power management settings in the BIOS setup. As a database professional, this is something you would want to investigate and correct.

The CPU tab also shows that this processor is x64 compatible, since we see EM64T as one of the supported instructions. We can also see the size and types of the L1, L2, and L3 caches. Finally, I can see that this processor has eight cores and sixteen threads, which means that it has hyper-threading, and hyper-threading is enabled.

The Caches tab shown in Figure 2 gives you a lot of more detailed information about the L1, L2 and L3 caches.

image thumb2 A SQL Server Hardware Tidbit a Day – Day 5

Figure 2: Caches tab of CPU-Z 1.63

The Mainboard tab shown in Figure 3 gives you a lot of useful information about the motherboard, chipset, and main BIOS version.

 

image thumb3 A SQL Server Hardware Tidbit a Day – Day 5

Figure 3: Mainboard tab of CPU-Z 1.63

Figures 4 and 5 show the Memory and Serial Presence Detect (SPD) tabs of CPU-Z, which give you very useful information about the type and amount of memory that you have in your machine. In this case, we can see that we have 65460 MBytes of DDR3 RAM, (which is 64GB), and it is running in Quad channel mode.

 

image thumb4 A SQL Server Hardware Tidbit a Day – Day 5

Figure 4: Memory tab of CPU-Z 1.63

On some machines, the SPD tab will be blank. This seems to depend on the type and age of your machine, and the version of CPU-Z that you are using. Sometimes, you can better results for your machine when a new version of CPU-Z is released. In this case, we are getting complete information about the exact type and size of the memory modules that are in each slot of the Dell PowerEdge R720 machine, as shown in Figure 5.

image thumb5 A SQL Server Hardware Tidbit a Day – Day 5

Figure 5: SPD tab of CPU-Z 1.63

Over the many times that I have talked about using CPU-Z, I have gotten a few  questions about whether it is safe to run on a production SQL Server. All I can say is that I have been using it myself for many years, with absolutely no problems. Many other well-known people in the SQL Server community have been doing the same thing. I think it is an extremely valuable tool for confirming some important information about the processors in your database servers.

If you don’t feel comfortable using this tool, then don’t use it…

A SQL Server Hardware Tidbit a Day – Day 4

Since 2006, Intel has adopted what they call a Tick-Tock strategy for developing and releasing new processor models. Every two years, they introduce a new processor family, incorporating a new microarchitecture; this is the Tock release. One year after the Tock release, they introduce a new processor family that uses the same microarchitecture as the previous year’s Tock release, but using a smaller manufacturing process technology and usually incorporating other improvements such as larger cache sizes or improved memory controllers. This is the Tick release.

This Tick-Tock release strategy benefits the DBA in a number of ways. It offers better predictability regarding when major (Tock) and minor (Tick) releases will be available. This helps you plan your upgrade strategy and schedule.

Tick releases are usually socket-compatible with the previous year’s Tock release, which makes it easier for the system manufacturer to make the latest Tick release processor available in existing server models more quickly, without completely redesigning the system. In most cases, only a BIOS update is required to allow an existing system to use a newer Tick release processor. This makes it easier for you to maintain servers that are using the same model number (such as a Dell PowerEdge R720 server), since the server model will have a longer manufacturing life span.

As a DBA, you need to know where a particular processor falls in Intel’s processor family tree if you want to be able to meaningfully compare the relative performance of two different processors. Historically, processor performance has nearly doubled with each new Tock release, while performance usually goes up by 20-25% with a Tick release. This historical pattern is starting to change as Intel is beginning to focus more on power efficiency rather that increasing single-threaded performance.

Some of the recent and upcoming Intel Tick-Tock releases are shown in Figure 1.

ticktock infographic web.jpg.rendition.cq5dam.thumbnail.920.460 A SQL Server Hardware Tidbit a Day – Day 4

Figure 1: Intel’s Tick-Tock Release Strategy

 

The manufacturing process technology refers to the size of the individual circuits and transistors on the chip. The Intel 4004 (released in 1971) series used a 10-micron process; the smallest feature on the processor was 10 millionths of a meter across. By contrast, the Intel Xeon “Sandy Bridge” E5 series (released in 2012) uses a 32nm process. For comparison, a nanometer is one billionth of a meter, so 10-microns would be 10000 nanometers! This ever-shrinking manufacturing process is important for two main reasons:

Increased performance and lower power usage – even at the speed of light, distance matters, so having smaller components that are closer together on a processor means better performance and lower power usage.
Lower manufacturing costs – since you can produce more processors from a standard silicon wafer. This helps make more powerful and more power efficient processors available at a lower cost, which is beneficial to everyone, but especially for the database administrator.

The first Tock release was the Intel Core microarchitecture, which was introduced as the dual-core “Woodcrest” (Xeon 5100 series) in 2006, with a 65nm process technology. This was followed up by a shrink to 45nm process technology in the dual-core “Wolfdale”  (Xeon 5200 series) and quad-core “Harpertown” processors (Xeon 5400 series) in late 2007, both of which were Tick releases.

The next Tock release was the Intel “Nehalem” microarchitecture (Xeon 5500 series), which used a 45nm process technology, introduced in late 2008. In 2010, Intel released a Tick release, code-named “Westmere” (Xeon 5600 series) that shrank to 32nm process technology in the server space. In 2011, the Sandy Bridge Tock release debuted with the E3-1200 series for single socket servers and workstations.  All of these other examples are for two socket servers, but Intel uses Tick Tock for all of their processors. Figure 2 shows this “family history” for Intel server processors.

Year

Process

Model Families

Code Name

2006

65nm

3000, 3200, 5100, 7300

Woodcrest, Clovertown

2007

45nm

3100, 3300, 5400, 7400

Wolfdale, Harpertown

2008

45nm

3400, 3500, 5500, 7500

Nehalem-EP, Nehalem-EX (2010)

2010

32nm

3600, 5600, E7-4800

Westmere-EP, Westmere-EX (2011)

2011

32nm

E3-1200, E5-2600

Sandy Bridge, Sandy Bridge-EP (2012)

2012

22nm

E3-1200 v2, E5-2600 v2

Ivy Bridge, Ivy Bridge-EP/EX (2013)

2013

22nm

E3-1200 v3, E5-2600 v3

Haswell, Haswell-EP (2014 ?)

2014

14nm

Rockwell

2015

14nm

Skylake

2016

10nm

Skymont

Figure 2: Recent and Upcoming Intel Processor Families

How to Find Out About the Latest SQL Server Service Packs and Cumulative Updates

Since someone asked me about this today, I thought I would write about it.  Aaron Bertrand (blog|twitter) and I sort of have a friendly competition to be the first to blog when a new SQL Server CU is released.  I don’t know of any e-mail notification service for Service Packs and Cumulative Updates from Microsoft. There used to be RSS feeds that you could subscribe to, but I don’t think they are working anymore. One valuable resource is the SQL Server Release Services Blog, but it is not always updated in a timely fashion.

SQL Server Release Services Blog

The Update Center shows the latest release for each major version going back to SQL Server 2000.

Update Center for Microsoft SQL Server

 

These KB articles listed below are updated whenever a new CU is released, and it usually happens pretty quickly. There won’t be any more Cumulative Updates for the KB articles that are marked (retired branch).

SQL Server 2012

The SQL Server 2012 builds that were released after SQL Server 2012 was released

The SQL Server 2012 builds that were released after SQL Server 2012 Service Pack 1 was released

 

SQL Server 2008 R2

The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 was released  (retired branch)

The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 Service Pack 1 was released

The SQL Server 2008 R2 builds that were released after SQL Server 2008 R2 Service Pack 2 was released

 

SQL Server 2008

The SQL Server 2008 builds that were released after SQL Server 2008 was released  (retired branch)

The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 1 was released  (retired branch)

The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 2 was released  (retired branch)

The SQL Server 2008 builds that were released after SQL Server 2008 Service Pack 3 was released

 

To be honest, what I typically do to discover new Cumulative Updates is that I set a calendar reminder for seven weeks after the last Cumulative Update, and then I start checking those updating KB articles for the next week or so after that to find out when a new CU has been released. Microsoft is pretty mysterious when it comes to announcing new Service Packs and Cumulative Updates. Sometimes there is a big announcement, and sometimes you have to do some detective work.