Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 


 
     
Recent Posts
   
Popular Topics
Home   
Search
    Members    Calendar    Who's On

Home » SQL Server 2005 » Administering » Move Primary Key to File Group?
Add to briefcase
11 posts, Page 1 of 2
12»»

Move Primary Key to File Group? Expand / Collapse
Rate Topic
Display Mode
Topic Options
Author
Message
Fraggle-805517
Posted Friday, March 08, 2013 2:00 PM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, May 09, 2013 8:15 AM
Points: 716, Visits: 1,317
Was wondering if anyone was aware of any papers or best practices they could point me to regarding moving Clustered Primary Keys off of the primary file group and onto another file group.

Thanks,

Fraggle
Post #1428767
opc.three
Posted Friday, March 08, 2013 3:08 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:37 PM
Points: 6,720, Visits: 11,755
Like how to move them? Lookup CREATE INDEX, and specifically the DROP_EXISTING and ON [filegroup] options.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1428780
SQLRNNR
Posted Friday, March 08, 2013 3:34 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: 2 days ago @ 1:07 PM
Points: 18,733, Visits: 12,332
Quick article on how to do this here
http://saveadba.blogspot.com/2012/02/move-clustered-index-new-filegroup.html


Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1428801
Fraggle-805517
Posted Friday, March 08, 2013 3:59 PM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, May 09, 2013 8:15 AM
Points: 716, Visits: 1,317
Sorry guys. I wasn't very clear. I already have a script to move all index (except primary keys) to a different file group. However, with Primary Keys, the rules change. I can't just use the DROP_EXISTING option. It doesn't work. At lease not in 2005 Enterprise. FK constraints and such make this difficult.

Specifically, what I am trying to figure out is what is best practice about moving the Clustered or Non-clustered index on a table, that is also the primary key constraint to another file group?

So if I have the following table

create table tbl1
(id int primary key clustered,
col1 int,
col2 int,
col3 int
)
create nonclustered index idx1 on tbl1 (col1)
create nonclustered index idx2 on tbl1 (col3,col2)

Moving IDX1 and IDX2 to the new file group, which is on a separate disk from the table, makes sense. However, what about the clustered primary key index? What is best practice on this? What if it was a nonclustered primary key?

I hope this makes it more clear as to what I am asking.

Thanks,

Fraggle
Post #1428806
SQLRNNR
Posted Friday, March 08, 2013 4:07 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: 2 days ago @ 1:07 PM
Points: 18,733, Visits: 12,332
If you feel you must move them, then script out the drop statements for the FKs, script out the table move to the new filegroup, and then script out the create statements for the FKs.


I'd rather keep the PKs where they are, or plan in advance. When creating a table - create it in the appropriate filegroup so you don't have to move them.

BP is considered to create a separate filegroup for tables and objects separate from the primary filegroup (initial data file), but not necessarily to separate all indexes from the data. When doing a piecemeal restore, you have to have the indexes and data filegroups restored anyway, so I like to keep those together and break into filegroups in a different manner.


Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1428808
opc.three
Posted Friday, March 08, 2013 4:26 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 4:37 PM
Points: 6,720, Visits: 11,755
I saw "clustered" and breezed right past "primary." Constraints have to be dropped and re-added, which brings FKs and NC indexes into it as well. Messy.

__________________________________________________________________________________________________
There are no special teachers of virtue, because virtue is taught by the whole community. --Plato

Believe you can and you're halfway there. --Theodore Roosevelt

Everything Should Be Made as Simple as Possible, But Not Simpler --Albert Einstein

The significant problems we face cannot be solved at the same level of thinking we were at when we created them. --Albert Einstein

1 apple is not exactly 1/8 of 8 apples. Because there are no absolutely identical apples. --Giordy
Post #1428812
Fraggle-805517
Posted Saturday, March 09, 2013 11:30 AM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, May 09, 2013 8:15 AM
Points: 716, Visits: 1,317
General question here, but I am under the impression that a clustered primary key index, is essentially the table itself. If that is the case, does it make sense to move it to the new file group with the other non-clustered index?

Fraggle
Post #1428915
SQLRNNR
Posted Saturday, March 09, 2013 8:23 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: 2 days ago @ 1:07 PM
Points: 18,733, Visits: 12,332
Fraggle-805517 (3/9/2013)
General question here, but I am under the impression that a clustered primary key index, is essentially the table itself. If that is the case, does it make sense to move it to the new file group with the other non-clustered index?

Fraggle


Yes, the clustered index is the data of the table. And yes it would make sense to keep that (in most cases) with the other indexes for that table. There are some setups where people do not want to keep that in the same data file as the indexes.


Jason AKA CirqueDeSQLeil
I have given a name to my pain...
MCM SQL Server 2008

SQL RNNR

Posting Performance Based Questions - Gail Shaw
Posting Data Etiquette - Jeff Moden
Hidden RBAR - Jeff Moden
VLFs and the Tran Log - Kimberly Tripp
Post #1428949
Fraggle-805517
Posted Saturday, March 09, 2013 9:01 PM
Right there with Babe

Right there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with BabeRight there with Babe

Group: General Forum Members
Last Login: Thursday, May 09, 2013 8:15 AM
Points: 716, Visits: 1,317
SQLRNNR (3/9/2013)
Fraggle-805517 (3/9/2013)
General question here, but I am under the impression that a clustered primary key index, is essentially the table itself. If that is the case, does it make sense to move it to the new file group with the other non-clustered index?

Fraggle


Yes, the clustered index is the data of the table. And yes it would make sense to keep that (in most cases) with the other indexes for that table. There are some setups where people do not want to keep that in the same data file as the indexes.


Could you elaborate more on some of the reasons why you would not want to keep the clustered indexes in the same place as the indexes.

Thanks

Fraggle
Post #1428953
Lynn Pettis
Posted Sunday, March 10, 2013 12:49 PM


SSC-Insane

SSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-InsaneSSC-Insane

Group: General Forum Members
Last Login: Today @ 4:34 PM
Points: 21,615, Visits: 27,445
It is possible that to improve system performance, you could more your nonclustered indexes to other file groups and have this file groups on separate spindles. This could allow for parallel access between the NCI and the CI possibly improving performance for bookmark lookups. Also, if the NCI are covering indexes and are on separate spindle(s), this would reduce reads from the file group and disks where the CI reside.

All of this could help increase performance. YMMV, so this needs to be tested completely in a test environment before being implemented in production.


Lynn Pettis

For better assistance in answering your questions, click here
For tips to get better help with Performance Problems, click here
For Running Totals and its variations, click here or when working with partitioned tables
For more about Tally Tables, click here
For more about Cross Tabs and Pivots, click here and here
Managing Transaction Logs

SQL Musings from the Desert Fountain Valley SQL (My Mirror Blog)
Post #1429004
« Prev Topic | Next Topic »

Add to briefcase
11 posts, Page 1 of 2
12»»

Permissions Expand / Collapse

 
 
Copyright © 2002-2013 Simple Talk Publishing. All Rights Reserved. Privacy Policy. Terms of Use. Report Abuse.