Move Primary Key to File Group?

  • 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

  • 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

  • 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[/url]
    Learn Extended Events

  • 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

  • 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[/url]
    Learn Extended Events

  • 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

  • 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

  • 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[/url]
    Learn Extended Events

  • 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

  • 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 (3/10/2013)


    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.

    Exactly. It all depends on the environment, data access patterns, and hardware. The important thing is to test, test, and test.

    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

Viewing 11 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic. Login to reply