Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Transparent partitioning. Expand / Collapse
Author
Message
Posted Thursday, August 23, 2012 2:35 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, December 14, 2014 3:41 PM
Points: 257, Visits: 1,225
My view in the world is that partitioning should be transparent to the user and to the 'programmer'.

So a field [Partitioning_Key] should not appear in the code, but still work efficiently. So the same code can be used for situations where there is a [Partitioning_Key] and were there isn't.
So I would like to define this as:

[Partitioning_Key] AS ([Clientnumber]%(31)) PERSISTED,

My questions:
1. Is my thinking correct?
(Or should the programmer code with the partitioning in mind?)
2. Is the SQL-server capable of using the partioning effective, if the code does not use the [Partitioning_Key] in the where or in the ON clauses?

For master and detail tables the partitioning will be the same. So all the data belonging to a client has the same Clientnumber and the same [Partitioning_Key].

Or can performance be improved by adding to the code, for example adding the [Partitioning_Key] to the ON part of a JOIN clause and adding it to the WHERE clause?
(This makes two code streams one for partitioning and one for non partioning, alternatively use the same code and just have a partitioning key field and not using it in the non partioned world).

Thanks for your time and attention.
Ben Brugman
Post #1348939
Posted Thursday, August 23, 2012 3:22 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Monday, November 3, 2014 8:05 AM
Points: 1,191, Visits: 9,892
If your partitioning key is not referenced at all in queries, then, generally speaking, it will give no performance gains as it will have to scan each partition to find the rows to satisfy the query. *

The point of partitioning is normally to divide your tables using a natural key, like a transaction date, or a month end date etc. in order to immediately narrow down the portion of the dataset that needs to be accessed.

If your clientnumber is a sequential number, you may be able to get gains by defining your partition as ranges of client numbers, but this isn't a simple subject and you shouldn't just jump into partitioning tables without knowing in detail how partitioning works in SQL Server, that you actually require them and what it means for queries.

What sort of data volumes are you dealing with in these tables? Is there always going to be a seek to a specific client number that's already highly selective?


*There are some use cases for a hashing partition like this, but it's not for typical OLTP workloads
Post #1348963
Posted Thursday, August 23, 2012 4:36 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 9:13 AM
Points: 40,609, Visits: 37,070
Just a note, partitioning is not about performance improvements most of the time. It's about maintenance, data loads, archiving and things like that.


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1349001
Posted Monday, August 27, 2012 8:04 AM
SSC Veteran

SSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC VeteranSSC Veteran

Group: General Forum Members
Last Login: Sunday, December 14, 2014 3:41 PM
Points: 257, Visits: 1,225
HowardW (8/23/2012)

:
The point of partitioning is normally to divide your tables using a natural key, like a transaction date, or a month end date etc. in order to immediately narrow down the portion of the dataset that needs to be accessed.
:
What sort of data volumes are you dealing with in these tables? Is there always going to be a seek to a specific client number that's already highly selective?


The clientnumbers are used a lot and highly selective. But partitioning is done by a modulo function of the clientnumbers to get an even spread over the partitions. The detail tables use the same partitioning key, most of the detail tables do not have the clientnumber but the partitioning key is there.

HowardW (8/23/2012)

*There are some use cases for a hashing partition like this, but it's not for typical OLTP workloads

GilaMonster (8/23/2012)
Just a note, partitioning is not about performance improvements most of the time. It's about maintenance, data loads, archiving and things like that.


Both of you thank for the last remarks. Partitioning is not designed for OLTP and partitioning is not designed to be transparrant.
This does clear some of my misunderstandings about partitioning.

Thanks for setting me straight,
ben

Post #1350401
Posted Monday, August 27, 2012 8:23 AM


SSC-Forever

SSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-ForeverSSC-Forever

Group: General Forum Members
Last Login: Today @ 9:13 AM
Points: 40,609, Visits: 37,070
I wouldn't go as far as saying it's not for OLTP, for any form of sliding windows where you periodically need to purge older data from a table, it can be awesome and that 's something OLTP does have.


Gail Shaw
Microsoft Certified Master: SQL Server 2008, MVP
SQL In The Wild: Discussions on DB performance with occasional diversions into recoverability

We walk in the dark places no others will enter
We stand on the bridge and no one may pass

Post #1350417
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse