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 12»»

Move Primary Key to File Group? Expand / Collapse
Author
Message
Posted Friday, March 8, 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, December 18, 2014 9:54 PM
Points: 727, Visits: 1,436
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
Posted Friday, March 8, 2013 3:08 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:56 AM
Points: 7,140, Visits: 12,764
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
Post #1428780
Posted Friday, March 8, 2013 3:34 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 2:39 PM
Points: 18,064, Visits: 16,108
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, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #1428801
Posted Friday, March 8, 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, December 18, 2014 9:54 PM
Points: 727, Visits: 1,436
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
Posted Friday, March 8, 2013 4:07 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 2:39 PM
Points: 18,064, Visits: 16,108
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, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #1428808
Posted Friday, March 8, 2013 4:26 PM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:56 AM
Points: 7,140, Visits: 12,764
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
Post #1428812
Posted Saturday, March 9, 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, December 18, 2014 9:54 PM
Points: 727, Visits: 1,436
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
Posted Saturday, March 9, 2013 8:23 PM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Today @ 2:39 PM
Points: 18,064, Visits: 16,108
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, MVP


SQL RNNR

Posting Performance Based Questions - Gail Shaw
Post #1428949
Posted Saturday, March 9, 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, December 18, 2014 9:54 PM
Points: 727, Visits: 1,436
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
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 @ 2:40 PM
Points: 20,863, Visits: 32,901
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 12»»

Permissions Expand / Collapse