Why You Should Use Database Compression on Your Dynamics Database
Data storage is relatively cheap in the server hardware world, but I think every DBA and IT Operations person would much rather have a 300 GB database than a 700 GB database. Not only does it save you hard drive space, but it saves on previous backup and restore time.
If you have SQL Server Enterprise Edition on SQL 2008 or higher, you can use SQL Data Compression to achieve such a vast decrease in the size of your database. Compression also improves overall performance because more data is cached in the buffer pool, limiting the trips to the disk to read data. There is such limited downside to compression that I think nearly everyone should be deploying at least row compression in order to improve performance and reduce data storage.
What is Compression?
Database compression is the optimization of the storage of SQL data by eliminating unused space that has been reserved for that particular data record (ROW) or finding patterns in data that can be optimized by storing the common pattern once (PAGE). A basic example of row compression would be the storage of the word "Invoice" in a nchar(100) field. The "n" part of nchar tells me this is a Unicode datatype, so if I'm storing English data, I can save 50% of my space right away by storing the value as 1 byte instead of 2 (default for Unicode data is to store values as double-bytes to handle complex characters in languages such as Korean and Hebrew). The "char" part of nchar tells me that the database is reserving 100 characters for the value in that field, regardless of how long the word is. Since invoice is 7 characters, I'm storing an extra 93 characters worth of space in that field. This basic example shows how you could save 96.5% of your storage space on just this one field.
Row Compression
The above example showed the value of Row Compression which saves space by storing fixed-length data types in variable length storage. Row compression is the more basic version of database compression and is the one I think people should enable by default. Starting with SQL 2008 R2, both row and page compression take advantage of Unicode compression to save people using English or other European languages 50% of your text storage space right away (see article for more detail).
Page Compression
Page Compression is more complicated to explain but it incorporates the benefits of row compression and extends them with the ability to find common text in data and store it once and reference it instead of storing it over an over again. Let's say your invoice names in AX start with INV000 then a number. Page compression would store the INV000 in cache like a variable (let's call it "x"), so when you pull up the value INV00018, it would be stored as "x"18, thereby saving 5 characters worth of space. Because page compression looks for patterns in the data, it doesn't make sense to use it on setup tables or tables with limited row counts. It can provide huge value on large tables.
How to Deploy Compression
There are several different ways to enable compression depending on what product you are using. Within SQL, you can right-click on a table, choose Storage and Manage Compression and from there you can see how many rows of data exist in that table and you can calculate the value of compression on each table. For the Dynamics products, there are a few considerations to review when deploying compression:
Dynamics AX
If you are using AX, you need to make sure that the application knows about the compression, so when you synchronize your database, it doesn't remove the compression settings from the indexes. The simplest way to enable compression is to turn it on from the application using the SQL Setup table as outlined in this blog Becky posted: http://community.dynamics.com/product/ax/axtechnical/b/axsupport/archive/2012/10/21/ax-2012-database-how-to-enable-sql-compression-enterprise-edition.aspx. If you want to enable row compression across all tables (for example), you could just go in there and set it to run. (This should go without saying but make sure you do this in test with a full copy of your production database before you do it live). You could also use Michael DeVoe's compression tool to enable compression on select tables and update the SQL Storage table to reflect the changes you made at the database level which I'll explain further in a minute.
Dynamics NAV
You can enable compression through SQL directly or you can leverage the Microsoft SQL Server Data Compression Tool for Dynamics which is described here and available for Dynamics NAV and SQL database compression from this link. This tool will go through all your tables and provide recommendations on which tables should be Row compressed or Page compressed. The tool works across all Dynamics products, and if you are wanting to do an analysis of how to adopt compression, I highly recommend you read through the information and use that tool. You can reach out to the Microsoft Premier Field Engineering team directly and have them perform the service for you as well.
What's the Catch?
OK, as with everything, there is a bit of a catch. To repeat something from the top part of the post, you have to be on SQL Server Enterprise Edition to take advantage of Compression. If you're on that edition, the other catch is that compression will increase processor utilization by 10-30% depending on what you compress and how you compress it. If your processors are running at 10-30% of capacity, then I would highly recommend compression. If your processors are getting into the 50%+ capacity regularly, I would upgrade my processors, then put on compression (or don't put on compression if you can't upgrade your procs). If you are using replication or partitions, please read the articles referenced below for more detail on the different steps you will need to take.
For More Information
I referenced a number of links in this blog, but there are additional background articles I'd suggest you review when making the decision to enable compression:
Michael DeVoe did a session at Convergence some years ago on the value of Compression, so if you can find that archive, it's certainly worth reviewing.
Under the terms of this license, you are authorized to share and redistribute the content across various mediums, subject to adherence to the specified conditions: you must provide proper attribution to Stoneridge as the original creator in a manner that does not imply their endorsement of your use, the material is to be utilized solely for non-commercial purposes, and alterations, modifications, or derivative works based on the original material are strictly prohibited.
Responsibility rests with the licensee to ensure that their use of the material does not violate any other rights.