It’s been long time I’ve written any post and I’ve always been thinking of writing something unique. Finally, I got something 🙂 . Normally, I prefer to write long posts but this time I will try to keep it brief and precise.
I have been with working with a particular customer for a long time and wanted to share my success story through a series of blog posts. In this post, I will discuss about table partition which was a game changer for us.
1. The database size – 1 TB
2. Data insertion rate per day – approx. 25 GB
3. Long running transactions and heavy blocking entire day
4. Log shipping failure because of huge log file backups , sometimes 100 GB
5. Replication latency due to long running transactions.
6. Biggest table had 10,000,000,000 records(cause of the contention).
In my next posts , I will discuss about how did I conquer/win this battle. I will share my strategy of finding the tipping points and plan I followed.
Staying in the context, how do we normally choose our partition column. I have asked many of my colleagues and read some blogs, the answer was:
1. Check with the developers on what’s the most commonly used column in the where clause
2. Pick up the most expensive queries and check the where clause
3. Check if they want to archive the data based on financial year. If yes, then “of course” a date column.
If you ask me, all the answers are correct. The approach is correct but there are some caveats with this approach. Sometimes, it may not yield predictable results because if the customer is not aware of what’s there is where clauses or sometimes most expensive queries may not be using columns which need partitioning. As a result we may end up doing table partitioning based on a wrong column. I contemplated about it and tried to find a predictable approach.
Before I delve deeper, I would like to ask a question :
Lets say , in a book library – if the books are searched with the name of the book/author. Does it matter to organize the book based on the published dates.
Lets say if I have to organize a book library how will I decide what to keep where so that user can find the book as fast as possible?
The answer is , I will think about the search criteria of the user. If the user mostly search based on the subject and name of the book I will organize based on subject and then names in alphabetical order. In this particular case we already knew that we should always partition based on the subject because that’s what user will always search for in a library and then find a book based on the name.
In this case the most heaviest columns used will be subject of the book and then name of the book. But, how did we find this search criteria?
1. By checking with the experienced people
2. By learning from the other systems and experiences
3. By user feedback
if we see, all three are equally important. But lets say, if I am not sure if all three are 100% correct and in worst case, no one is aware of the search criteria. In that case, I need something more predictable and relevant. Sometimes, the system is very complex and it’s difficult to find out the perfect search criteria. That’s what this post is all about i.e. to find a right search column so that partition can be done optimally.
For this customer, here is what I started with:
1. Checked with the developers about the inputs on where clauses
2. Checked the archival strategy of the customer
and something more I did in conjunction with the above , as mentioned below:
It’s simple for the the tables , where the archival had to be performed based on dates we “had” to choose the date columns. For the tables, where there is no archival strategy and the size of the table is huge – how to choose a right partitioning column to have more predictable results. Trusting the inputs from developers/DBAs is not bad but we need to explore little more – to be more certain about this choice of the right partitioning column.
Here comes the gist :
After capturing all the above inputs, I also leveraged a DMV sys.dm_db_index_stats.
Note : Before using this DMV’s , make sure the SQL server instance is up and running for more than a week. The reason being, it’s output is based on the last startup time. More the startup time, more useful will be the information. For more information on this DMV, please check the link : http://technet.microsoft.com/en-us/library/ms188755.aspx
To set the context right, this DMV captures the information of the index usage like how many index seeks/scans/lookups and updates happened on an index since the last startup of the SQL server instance.
This DMV is the centre point of every query which is run on the SQL server. It gives us overview of which index is being hit most of the times and which index is not being used at all. If we think little deeper, it gives us overview of which column is being hit in where clause , most of the times eventually our search column.
If we see the above output, it clearly shows Index_id 10,2 is being hit most of the times. If we see the clustered index stats, it shows that this is not an optimal clustered index because most of the times, there are only key lookups.
Now the question arises, what if there are missing indexes with the user_seeks more than 25295223 , the answer is simple – create that index first and then do the analysis again. The end goal is to find out the column with the heaviest hits. If we are able to find that column and it also (may or may not) aligns with the customers input then surely we have got our column for partitioning.
If we relate back to the library example of Subject and the name of the book – here we can partition based on the index 10 and sort based on index 2. It calls for a composite partitioned index with index column id 2 and then partition column of index 10.
Now you may think : what if the index is composite index. In that case, the index seek will happen only when the search is based on the primary columns along with the secondary column. So, pick up the primary column.
This is a very precise and useful information which can be leveraged while partitioning instead of just trusting blindly what developers/DBAs say. The end goal of the whole exercise is to find out most heaviest search column so that partition can yield more predictable and fruitful results.