October 10, 2011 at 12:25 am
we don't have any experience to deal with partitioning. But we have a lot of older data (from previous years) that is rarely queried, but the data has to be available just in case someone wants to check it out. My original assumption is that all of the queries that use this table as part of their JOIN are going to operate slowly because of all the rows. There are some indexes on this table already. But I have a feeling that there needs to be a major database redesign. I wasn't involved with the original design and I am only taking over responsibility for it now. I foresee a time in the near future where we will do a redesign, so I thought that partitioning might prove beneficial for the next few months until I can take the time to redesign
October 10, 2011 at 5:04 am
In SQL Server 2005, all tables are essentially partitioned by default, they all exist in a default first partition (check the tables sys.partitions and sys.allocation_units). You will need to examine and understand the current table\index structure. You will need to decide on the partitioning column to be used and also its range values. The design of the partition scheme and function should be very carefully planned and implemented.
-----------------------------------------------------------------------------------------------------------
"Ya can't make an omelette without breaking just a few eggs" 😉
October 11, 2011 at 7:52 pm
I have never used the table partition in production before. I heard the table partition is better for OLAP data warehouse, is this true? If it is, does it have merit on OLTP database (I assume this question is about the OLAP database).
Alan
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply