December 13, 2010 at 10:08 pm
Comments posted to this topic are about the item Automate Sliding Window Partition Management: Part I
December 14, 2010 at 1:23 am
How about the case when new data starts to fill your topmost partition? How do you avoid unnecessary data movement?
When I implemented partitioning I had 2 topmost partitions and a SQL Agent Job running a SSIS package to react on the fullness of the second topmost partition. If it were getting full then we split the topmost partition. Only to avoid any kind of data movement.
/Johan Klövstedt
December 14, 2010 at 5:02 am
This article is actually in three parts. The next two parts describe automation of partition maintenance (adding partitions at the "top" and removing partitions from the "bottom").
My understanding is that they will be published next week and the week after.
Regards,
Hugh Scott
December 14, 2010 at 6:54 am
Awesome. This is really timely. I just got Enterprise approved so I can implement partitioning and this series is going to be a huge help. Is the Powershell script coming in one of the next articles. I didn't see it with this article.
December 14, 2010 at 8:02 am
can you partition a table where you keep say 30-45 days of data. have it partition by day or week to make deletes and inserts faster?
December 14, 2010 at 8:36 am
Excellent overview of Partitioning and Sliding-Window by Kimberly Tripp that provides background into why, how and technical implementation details.
http://msdn.microsoft.com/en-us/library/ms345146(SQL.90).aspx
December 14, 2010 at 8:59 am
The article states the following:
First off, you need SQL Server Enterprise Edition or Developer Edition. None of the other editions of SQL Server 2005 or 2008 support partitioning. SQL Server 2000 and earlier do not support partitioning at all.
This is not entirely correct, the devil is in the details!
Partitioning is supported, I believe all the way back to SQL Server 2000, but it works in an entirely different way then the more advanced method of partitioning functions. Which are indeed only available in Developer and Enterprise versions.
Here is an old script that I posted once on SQL ServerCentral.com to demonstrate partitioning at work using noting but several partition tables and a view to unify them as if they were one large table. And yes, you can insert in such views without writing any instead-of trigger on your part.
Some not so obvious restrictions (there always are those, sigh):
* When inserting records, you need to specify all columns, even those that accept NULL values.
* You cannot do a modification trough the view when the query also uses a "select" that references the unified view or one of its patritions.
The script is attached as a file for ease of use and contains some comments to help people on their way.
December 14, 2010 at 10:22 am
Are there any performance concerns when partitioning with a single filegroup apart from the restrictions on I/O increases from not using multiple disks? We're about to implement a partitioned table, and it looks like we're using just one filegroup. Every document I read talks on and on using 1 filegroup per 1 file, but I can't find much if any info on single filegroup solutions.
Secondly, I've read if you add an index to a partitioned table and you do not add the partitioned column to the index, SQL will add the partitioned column anyway in the background, thereby making any index added to a partitioned table aligned by default. Need some clarity on this point as well, because it has been suggested we do not need to add the partitioned column because of this. I would like to add it regardless just to be sure. Can't do that unless there's a reason.
-------------------------------------------------------------------------------------------------
My SQL Server Blog
December 14, 2010 at 10:46 am
Thanks for the article. I have a use for it already.
Jason...AKA CirqueDeSQLeil
_______________________________________________
I have given a name to my pain...MCM SQL Server, MVP
SQL RNNR
Posting Performance Based Questions - Gail Shaw[/url]
Learn Extended Events
December 14, 2010 at 11:55 am
peter-757102 (12/14/2010)
The article states the following:First off, you need SQL Server Enterprise Edition or Developer Edition. None of the other editions of SQL Server 2005 or 2008 support partitioning. SQL Server 2000 and earlier do not support partitioning at all.
This is not entirely correct, the devil is in the details!
Partitioning is supported, I believe all the way back to SQL Server 2000, but it works in an entirely different way then the more advanced method of partitioning functions. Which are indeed only available in Developer and Enterprise versions.
<snip>
That is called a Partitioned View. Although it looks similar, it is different from Partitioned Tables.
@Hugh, does the other parts of your article disucss what happens to the data and you move partions around? Or more importantly, how to avoid data movement? I think this is one area of Partioned Tables that really bites people who don't understand how/why Microsoft setup partioned tables like they did.
December 14, 2010 at 12:04 pm
I have implemented partitioning on a few larges tables. However, I switch over to single filegroup for ease of maintenance or lack of filegroup maintenance.
The underlying logical drives has 20 odd physical disks. Having each file in each filegroup does not make much difference in my setup.
December 14, 2010 at 12:42 pm
In reviewing the other two parts, I don't think I specifically address the idea of avoiding data movement (data moving from one file or file group to another because of changes to partition boundaries). However, that was one of my primary goals in implementing partitioning.
In the context of the sample database and the partitions that are included in this series, the method to avoid unnecessary data movement is to schedule the scripts to run just prior to the end of the month (in our case, a couple of days before the end of the month).
- SplitPartition.ps1 (covered next week) will create a new "top end" partition. By running it just before the end of the month *before new records are inserted beyond the new boundary date*, you can avoid data movement.
- MergePartition.ps1 (covered on the 28th) will eliminate the lowest trailing edge partition. This can really be done any time (in accordance with business rules and retention policy). MergePartition.ps1 avoids data movement by "switching" the data into a staging table on the same file group as the data that is to be removed, then dropping the partition and finally dropping the staging tables. In addition, it cleans up the files and file groups that are associated with the dropped partition.
By scheduling both scripts to run at the same time, I have a single job to track.
I should really have added this into the introduction or the summary of the series, but I'm glad that you pointed it out.
Regards,
Hugh
December 14, 2010 at 1:32 pm
Is there any performance gain when partitions are on the same set of spindles (can be same file group or different)?
December 14, 2010 at 1:54 pm
Thanks merlin for your reply and Hugh for this article. Looking forward to the next two installments.
Anybody have any idea what happens when you do not add the partitioned column to an index? Does it still create an aligned index (by secretly adding it anyway)?
-------------------------------------------------------------------------------------------------
My SQL Server Blog
December 14, 2010 at 2:55 pm
amenjonathan (12/14/2010)
Thanks merlin for your reply and Hugh for this article. Looking forward to the next two installments.Anybody have any idea what happens when you do not add the partitioned column to an index? Does it still create an aligned index (by secretly adding it anyway)?
Nope. The index gets created on the default file group. Not that I would know from experience!:-D
Regards,
Hugh
Viewing 15 posts - 1 through 15 (of 26 total)
You must be logged in to reply to this topic. Login to reply