This is the 4th and final article in a series on a database that needed to go on a diet for the New Year.
In the first article, I described why size really does matter, both for the DB itself, and all the other copies of it that exist in most organizations. I then showed how to estimate the improvement using ROW compression. Our customer’s database that started at 3.8TB was reduced to 2.6TB by applying ROW compression without code changes. Better still, the performance of the I/O bound application improved significantly.
In the second article, I showed how both ROW and PAGE compression change the internal structure of the database pages, and showed why PAGE compression could achieve such great size reductions.
In the third article, I provided guidance on how to decide whether to use ROW or PAGE compression, on a table by table, index by index, and partition by partition basis. By applying the recommendations in that article, the database had now dropped to 1.4TB and had even better performance than before.
In this final article, I’ll look at two other areas that were consuming a great deal of space within the database, and what I did about it.