What does the RCSI overhead mean?

Published On: 2013-06-05By:

Earlier I posted a blog post which talked about the fact that when you turn on readable secondary replicas there are an additional 14 bytes of overhead which are added to each row.

Overall the thought here is that the impact of this is probably pretty minimal. After all this is the same overhead for RCSI.  However where this becomes a problem is due to the page splitting that I mention in the other article and the fact that these 14 bytes don’t survive after an index rebuild but they do an index reorg.

I can see major page splitting issues happening on clustered indexes which are using the default fill factor of 100% full, which most clustered indexes use as that’s the correct fill factor to be using for a key column which is always growing.  But now as rows need to be changes within the clustered index that’s going to cause our clustered indexes, which never used to have to worry about page splits to suddenly start to split.

The solution here is that when using the readable secondary feature clustered indexes will need to account for this by using a fill factor other than 100% (or 0%) for the fill factor so that the page splits within the clustered index can be avoided.

Additionally we need to think long and hard about using index rebuilds or index reorgs when doing index maintenance.  If we have a table where the records are updated for a while then never updated again index rebuilds probably makes sense instead of index reorgs.  If however we are only doing index reorgs we are now storing an additional 14 bytes of data per row, eventually for most if not all of our rows for ever.  When talking about large tables that’s suddenly some actual space that needs to be accounted for.  For a table with 1 Billion rows that’s an additional 13 Gigs of additional space.  All in all not all that much space.  But if your 1 Billion row table has a row width of just 35 bytes your table should be about 33 Gigs, so an additional 13 Gigs of space is quite a lot.

I guess where I going here is that if you are going to be using AlwaysOn Availability Groups to protect your data and you are going to be using the readable secondary feature then there are going to be some other things within the database that you want to take into account.

Contact the Author | Contact DCAC


Globally Recognized Expertise

As Microsoft MVP’s and Partners as well as VMware experts, we are summoned by companies all over the world to fine-tune and problem-solve the most difficult architecture, infrastructure and network challenges.

And sometimes we’re asked to share what we did, at events like Microsoft’s PASS Summit 2015.

Awards & Certifications

Microsoft Partner   Denny Cherry & Associates Consulting LLC BBB Business Review    Microsoft MVP    Microsoft Certified Master VMWare vExpert
INC 5000 Award for 2020    American Business Awards People's Choice    American Business Awards Gold Award    American Business Awards Silver Award    FT Americas’ Fastest Growing Companies 2020   
Best Full-Service Cloud Technology Consulting Company       Insights Sccess Award    Technology Headlines Award    Golden Bridge Gold Award    CIO Review Top 20 Azure Solutions Providers
Share via
Copy link