Primary Key with Cluster Index

Hi All,

One of my client having 1 million(nearly) records in a table.
I defined the table as below
1) Created table with one col(we can name it as "ID") having IDENTITY
2) Using "alter table", I created CLUSTERED PRIMARY KEY Constraint on Same field (ID)
3) The Primary key having 2 ref with another 2 tables

Now the issue is when we create or define a primary key (With Clustered Option) automatically cluster Index will be created on defined table

As such table having huge data whenever any updation or insertion against that particular table taking huge amount of time, because the cluster Index trying re-paging whole data. Because of re-paging each and every time "Transaction Log also growing in huge" (database is in full recovery mode and client wants in same mode only)
Data partitioning not posible because whole data related and current live data

I tried following options with vain

1) To Clear transaction log I suggested to take regular log backup's
2) I tried to drop cluster index and tried to implement non clustered index
Drop and re-create index is take taking huge amount of time
Even in this process I have to Re_Index remaining Index's also

Pls give me any other solution or suggestion in this regard

with Thanks & Regards
BhaskaraFirst suggestion: pick a column name more descriptive than "ID"....

Second suggestion: one million rows is not that much data. Could there be some other reason why inserts are taking so long?

Third suggestion: you can reduce the number of initial page splits setting the fill factor lower when you create the index.|||If the clustered index is an identity then you are not getting page splits unless you are making changes to data attribute columns and increasing the size of this data. On inserts you are certainly not getting page splits - monotonically increasing clustered indexes like this will not create splits and are the fastest possible index for inserts (faster even than no clustered index).

Hang on - I just reread - are you changing the clustered index constantly?|||There appears to be more than one problem here, so it may take several steps to correct all of the problems.

First and foremost, you specified in your ALTER TABLE that you wanted the index to be clustered, so SQL Server dutifully did what you asked. That is not part of your problem at all.

A million rows is not a large table for SQL Server. A billion rows might be large, but a million definitely is not.

SQL Server disk I/O is what drives log usage. The log file is essentially a record of what changes were made to the database at the disk (binary) level.

Dropping a clustered index shouldn't be expensive in terms of time, but the server should not permit you to drop an index that is placed by the server to protect DRI (Declarative Referential Integrity). It shouldn't take a long time, but the DROP INDEX ought to fail.

When you create a new clustered index, it can cause massive amounts of I/O operations because a clustered index effectively rearranges the data store for the entire table. That means that every row in the table can (and probably will) move, and that every existing index on the table will need to be rebuilt.

When you change a table with a clustered index (using INSERT, UPDATE, or DELETE) the amount of I/O should be nearly the same as updating the same table without the clustered index. It is possible that you might have a page split that a heap insert would not incur, but the grand total of the I/O shouldn't be significantly different.

Whatever is causing the change in disk I/O and log file usage is almost certainly not the clustered index alone. Something else is either part or all of this problem.

To answer your questions as you posted them:

1) Take regular incremental backups to allow log space to be reused. This should not affect the time needed, but it will reduce the log file growth.

2) Dropping the clustered index should be impossible using DROP INDEX. I think you'll need to use ALTER TABLE to make this happen. Dropping the index ought to be quick, although creating a new index may take a while.

-PatP|||Dropping a clustered index shouldn't be expensive in terms of time

Unless there are other indexes on the table.|||are there any triggers on this table?|||If the clustered index is an identity then you are not getting page splits unless you are making changes to data attribute columns and increasing the size of this data. On inserts you are certainly not getting page splits - monotonically increasing clustered indexes like this will not create splits and are the fastest possible index for inserts (faster even than no clustered index).

Hang on - I just reread - are you changing the clustered index constantly?

Thanks for your interest in my problem
When I observed in Sql profiler, if there is any Insertion or Updation, it is trying re-page(indexing Pages) whole

come to last point made by you
Intially I declared it as clustered index, now because of slow performance i wanted it to drop and create NON-CLUSTER index|||Hi Pat Phelan,
Thanks for your interest in my problem

I Got what exactly you wanted to say
still I have some clarifications

1) I try to drop the clustered index using "ALTER TABLE" after removing DRI
and then I recreate the NONCLUSTERED INDEX using
"ALTER Table Document ADD CONSTRAINT PK_Document_id PRIMARY KEY NONCLUSTERED (id) ON [PRIMARY] "

whether it will give any impact on performance|||OK, you're dropping the constraint, not the index

Do you know what clustering means?

Primary Key Non-Cluster Index

Is there a case when the primary key should not be cluster index?
I have a SQL Server 2000 database that has several tables that have
non-cluster indexes for primary keys. Will this slow down the performance of
application that uses this table often?
Thank You,
Joe,
1. Yes. When the clustered index is better utilized on a different column
to support range and sorting queries.
2. It depends - on the type of queries that are being used in the
application.
HTH
Jerry
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:C3414875-894D-4F0E-87DE-46CA9A842CD8@.microsoft.com...
> Is there a case when the primary key should not be cluster index?
> I have a SQL Server 2000 database that has several tables that have
> non-cluster indexes for primary keys. Will this slow down the performance
> of
> application that uses this table often?
> Thank You,
|||On Tue, 25 Oct 2005 11:16:11 -0700, Joe K. <Joe
K.@.discussions.microsoft.com> wrote:
>Is there a case when the primary key should not be cluster index?
>I have a SQL Server 2000 database that has several tables that have
>non-cluster indexes for primary keys. Will this slow down the performance of
>application that uses this table often?
If there is NO clustered index on a table, and if you delete rows
(including if you update rows and because they need more space they
have to move), then you may wake up the (potentially evil) SQLServer
ghost.
Otherwise, whether a clustered index is going to help, or hurt, or do
nothing is highly dependent on application logic.
Josh
|||"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:C3414875-894D-4F0E-87DE-46CA9A842CD8@.microsoft.com...
> Is there a case when the primary key should not be cluster index?
> I have a SQL Server 2000 database that has several tables that have
> non-cluster indexes for primary keys. Will this slow down the performance
> of
> application that uses this table often?
> Thank You,
Of course. Keep in mind that a clustered index sorts the actual data rows
in index order. It is most often used when you are selecting on a range of
data like "OrderNumber Between 10 and 100", or you are sorting your data in
clustered index order.
If you are doing a lot of INSERTs into the table, the data must be placed in
clustered index order. If you are using a monotonically increasing value
(like IDENTITY), then there will always be space at the end of the last
datapage for your next row of data and page splitting doesn't occur. If you
are not using a monotonically increasing value, for example, LastName or a
GUID, then the database will have to make space for the new row if there is
not space already. This can cause page splitting which is time consuming
and resource consuming.
The performance of other applications depends on what those applications are
querying for.
Rick Sawtell
MCT, MCSD, MCDBA
sql

Primary Key Non-Cluster Index

Is there a case when the primary key should not be cluster index?
I have a SQL Server 2000 database that has several tables that have
non-cluster indexes for primary keys. Will this slow down the performance o
f
application that uses this table often?
Thank You,Joe,
1. Yes. When the clustered index is better utilized on a different column
to support range and sorting queries.
2. It depends - on the type of queries that are being used in the
application.
HTH
Jerry
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:C3414875-894D-4F0E-87DE-46CA9A842CD8@.microsoft.com...
> Is there a case when the primary key should not be cluster index?
> I have a SQL Server 2000 database that has several tables that have
> non-cluster indexes for primary keys. Will this slow down the performance
> of
> application that uses this table often?
> Thank You,|||On Tue, 25 Oct 2005 11:16:11 -0700, Joe K. <Joe
K.@.discussions.microsoft.com> wrote:
>Is there a case when the primary key should not be cluster index?
>I have a SQL Server 2000 database that has several tables that have
>non-cluster indexes for primary keys. Will this slow down the performance
of
>application that uses this table often?
If there is NO clustered index on a table, and if you delete rows
(including if you update rows and because they need more space they
have to move), then you may wake up the (potentially evil) SQLServer
ghost.
Otherwise, whether a clustered index is going to help, or hurt, or do
nothing is highly dependent on application logic.
Josh|||"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:C3414875-894D-4F0E-87DE-46CA9A842CD8@.microsoft.com...
> Is there a case when the primary key should not be cluster index?
> I have a SQL Server 2000 database that has several tables that have
> non-cluster indexes for primary keys. Will this slow down the performance
> of
> application that uses this table often?
> Thank You,
Of course. Keep in mind that a clustered index sorts the actual data rows
in index order. It is most often used when you are selecting on a range of
data like "OrderNumber Between 10 and 100", or you are sorting your data in
clustered index order.
If you are doing a lot of INSERTs into the table, the data must be placed in
clustered index order. If you are using a monotonically increasing value
(like IDENTITY), then there will always be space at the end of the last
datapage for your next row of data and page splitting doesn't occur. If you
are not using a monotonically increasing value, for example, LastName or a
GUID, then the database will have to make space for the new row if there is
not space already. This can cause page splitting which is time consuming
and resource consuming.
The performance of other applications depends on what those applications are
querying for.
Rick Sawtell
MCT, MCSD, MCDBA

Primary Key Non-Cluster Index

Is there a case when the primary key should not be cluster index?
I have a SQL Server 2000 database that has several tables that have
non-cluster indexes for primary keys. Will this slow down the performance of
application that uses this table often?
Thank You,Joe,
1. Yes. When the clustered index is better utilized on a different column
to support range and sorting queries.
2. It depends - on the type of queries that are being used in the
application.
HTH
Jerry
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:C3414875-894D-4F0E-87DE-46CA9A842CD8@.microsoft.com...
> Is there a case when the primary key should not be cluster index?
> I have a SQL Server 2000 database that has several tables that have
> non-cluster indexes for primary keys. Will this slow down the performance
> of
> application that uses this table often?
> Thank You,|||On Tue, 25 Oct 2005 11:16:11 -0700, Joe K. <Joe
K.@.discussions.microsoft.com> wrote:
>Is there a case when the primary key should not be cluster index?
>I have a SQL Server 2000 database that has several tables that have
>non-cluster indexes for primary keys. Will this slow down the performance of
>application that uses this table often?
If there is NO clustered index on a table, and if you delete rows
(including if you update rows and because they need more space they
have to move), then you may wake up the (potentially evil) SQLServer
ghost.
Otherwise, whether a clustered index is going to help, or hurt, or do
nothing is highly dependent on application logic.
Josh|||"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:C3414875-894D-4F0E-87DE-46CA9A842CD8@.microsoft.com...
> Is there a case when the primary key should not be cluster index?
> I have a SQL Server 2000 database that has several tables that have
> non-cluster indexes for primary keys. Will this slow down the performance
> of
> application that uses this table often?
> Thank You,
Of course. Keep in mind that a clustered index sorts the actual data rows
in index order. It is most often used when you are selecting on a range of
data like "OrderNumber Between 10 and 100", or you are sorting your data in
clustered index order.
If you are doing a lot of INSERTs into the table, the data must be placed in
clustered index order. If you are using a monotonically increasing value
(like IDENTITY), then there will always be space at the end of the last
datapage for your next row of data and page splitting doesn't occur. If you
are not using a monotonically increasing value, for example, LastName or a
GUID, then the database will have to make space for the new row if there is
not space already. This can cause page splitting which is time consuming
and resource consuming.
The performance of other applications depends on what those applications are
querying for.
Rick Sawtell
MCT, MCSD, MCDBA

Primary Key Convert from Non-Cluster to Cluster Index

How do I convert a primary key field that was created with a non-cluster
index to a
cluster index?
Please help me complete this task.
Thank You,
Script all foreign keys that refer to the PK.
Script all nonclustered indexes
Drop all Foreign keys
Drop all nonclustered indexes
Drop the PK
Create the PK as a clustered index
Create the other non-clustered indexes from the earlier script
Create the foreign key references from the earlier script.
Test this at least twice on a development/test environment.
I recently did this on a table with 26 foreign key references. There is no
short cut.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
> How do I convert a primary key field that was created with a non-cluster
> index to a
> cluster index?
> Please help me complete this task.
> Thank You,
>
>
|||I believe that you can go from nc to cl for a PK or UQ constraint using CREATE INDEX ... WITH
DROP_EXISTING. It is the other way (cl to nc) that you cannot do using DROP_EXISTING. I'd test it,
but I've been working straight for 15 hours now, so time for some sleep... :-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
> Script all foreign keys that refer to the PK.
> Script all nonclustered indexes
> Drop all Foreign keys
> Drop all nonclustered indexes
> Drop the PK
> Create the PK as a clustered index
> Create the other non-clustered indexes from the earlier script
> Create the foreign key references from the earlier script.
> Test this at least twice on a development/test environment.
> I recently did this on a table with 26 foreign key references. There is no short cut.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
> news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
>
|||Ahh, come to think about it, the FK's most probably have to be dropped even when using
DROP_EXISTING.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
> Script all foreign keys that refer to the PK.
> Script all nonclustered indexes
> Drop all Foreign keys
> Drop all nonclustered indexes
> Drop the PK
> Create the PK as a clustered index
> Create the other non-clustered indexes from the earlier script
> Create the foreign key references from the earlier script.
> Test this at least twice on a development/test environment.
> I recently did this on a table with 26 foreign key references. There is no short cut.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
> news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
>
|||It was from NC to CL that my latest script covered. 26 Foreign Keys.
Arrgh.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:umz77K86FHA.2364@.TK2MSFTNGP12.phx.gbl...
>I believe that you can go from nc to cl for a PK or UQ constraint using
>CREATE INDEX ... WITH DROP_EXISTING. It is the other way (cl to nc) that
>you cannot do using DROP_EXISTING. I'd test it, but I've been working
>straight for 15 hours now, so time for some sleep... :-)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
> news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
>
|||On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
<tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>Ahh, come to think about it, the FK's most probably have to be dropped even when using
>DROP_EXISTING.
But won't the EM do all the voodoo for you?
J.
|||> But won't the EM do all the voodoo for you?
Hmm, *without testing*, I bet a beer that EM will drop all foreign keys, drop the index, create the
index and re-create the foreign keys. I doubt that EM is smart enough to execute CREATE INDEX ...
WITH DROP_EXISTING.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"jxstern" <jxstern@.nowhere.xyz> wrote in message news:5ck4o1te08umautq0u1v1l379f8ik3rmlu@.4ax.com...
> On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
> <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
> But won't the EM do all the voodoo for you?
> J.
>
|||Your correct, all the Index Tuning Wizard recommends is to drop all indexes
except the cluster index. This is not much help.
What is a good way to analysis tuning indexes?
Thank You,
"Tibor Karaszi" wrote:

> Hmm, *without testing*, I bet a beer that EM will drop all foreign keys, drop the index, create the
> index and re-create the foreign keys. I doubt that EM is smart enough to execute CREATE INDEX ...
> WITH DROP_EXISTING.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "jxstern" <jxstern@.nowhere.xyz> wrote in message news:5ck4o1te08umautq0u1v1l379f8ik3rmlu@.4ax.com...
>
>
|||> What is a good way to analysis tuning indexes?
IMO, the brain. Know the datamodel, the data and work the query and execution plan. ITW can be some
input, but not a replacement.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:514AC714-27B8-424F-9890-261FCE34A769@.microsoft.com...[vbcol=seagreen]
> Your correct, all the Index Tuning Wizard recommends is to drop all indexes
> except the cluster index. This is not much help.
> What is a good way to analysis tuning indexes?
> Thank You,
>
> "Tibor Karaszi" wrote:

Primary Key Convert from Non-Cluster to Cluster Index

How do I convert a primary key field that was created with a non-cluster
index to a
cluster index?
Please help me complete this task.
Thank You,Script all foreign keys that refer to the PK.
Script all nonclustered indexes
Drop all Foreign keys
Drop all nonclustered indexes
Drop the PK
Create the PK as a clustered index
Create the other non-clustered indexes from the earlier script
Create the foreign key references from the earlier script.
Test this at least twice on a development/test environment.
I recently did this on a table with 26 foreign key references. There is no
short cut.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
> How do I convert a primary key field that was created with a non-cluster
> index to a
> cluster index?
> Please help me complete this task.
> Thank You,
>
>|||I believe that you can go from nc to cl for a PK or UQ constraint using CREA
TE INDEX ... WITH
DROP_EXISTING. It is the other way (cl to nc) that you cannot do using DROP_
EXISTING. I'd test it,
but I've been working straight for 15 hours now, so time for some sleep... :
-)
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
> Script all foreign keys that refer to the PK.
> Script all nonclustered indexes
> Drop all Foreign keys
> Drop all nonclustered indexes
> Drop the PK
> Create the PK as a clustered index
> Create the other non-clustered indexes from the earlier script
> Create the foreign key references from the earlier script.
> Test this at least twice on a development/test environment.
> I recently did this on a table with 26 foreign key references. There is n
o short cut.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
> news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
>|||Ahh, come to think about it, the FK's most probably have to be dropped even
when using
DROP_EXISTING.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
> Script all foreign keys that refer to the PK.
> Script all nonclustered indexes
> Drop all Foreign keys
> Drop all nonclustered indexes
> Drop the PK
> Create the PK as a clustered index
> Create the other non-clustered indexes from the earlier script
> Create the foreign key references from the earlier script.
> Test this at least twice on a development/test environment.
> I recently did this on a table with 26 foreign key references. There is n
o short cut.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
> news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
>|||It was from NC to CL that my latest script covered. 26 Foreign Keys.
Arrgh.
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:umz77K86FHA.2364@.TK2MSFTNGP12.phx.gbl...
>I believe that you can go from nc to cl for a PK or UQ constraint using
>CREATE INDEX ... WITH DROP_EXISTING. It is the other way (cl to nc) that
>you cannot do using DROP_EXISTING. I'd test it, but I've been working
>straight for 15 hours now, so time for some sleep... :-)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
> news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
>|||On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
<tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>Ahh, come to think about it, the FK's most probably have to be dropped even
when using
>DROP_EXISTING.
But won't the EM do all the voodoo for you?
J.|||> But won't the EM do all the voodoo for you?
Hmm, *without testing*, I bet a beer that EM will drop all foreign keys, dro
p the index, create the
index and re-create the foreign keys. I doubt that EM is smart enough to exe
cute CREATE INDEX ...
WITH DROP_EXISTING.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"jxstern" <jxstern@.nowhere.xyz> wrote in message news:5ck4o1te08umautq0u1v1l379f8ik3rmlu@.
4ax
.com...
> On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
> <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
> But won't the EM do all the voodoo for you?
> J.
>|||Your correct, all the Index Tuning Wizard recommends is to drop all indexes
except the cluster index. This is not much help.
What is a good way to analysis tuning indexes?
Thank You,
"Tibor Karaszi" wrote:

> Hmm, *without testing*, I bet a beer that EM will drop all foreign keys, d
rop the index, create the
> index and re-create the foreign keys. I doubt that EM is smart enough to e
xecute CREATE INDEX ...
> WITH DROP_EXISTING.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "jxstern" <jxstern@.nowhere.xyz> wrote in message news:5ck4o1te08umautq0u1v
1l379f8ik3rmlu@.4ax.com...
>
>|||> What is a good way to analysis tuning indexes?
IMO, the brain. Know the datamodel, the data and work the query and executio
n plan. ITW can be some
input, but not a replacement.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:514AC714-27B8-424F-9890-261FCE34A769@.microsoft.com...[vbcol=seagreen]
> Your correct, all the Index Tuning Wizard recommends is to drop all indexe
s
> except the cluster index. This is not much help.
> What is a good way to analysis tuning indexes?
> Thank You,
>
> "Tibor Karaszi" wrote:
>

Primary Key Convert from Non-Cluster to Cluster Index

How do I convert a primary key field that was created with a non-cluster
index to a
cluster index?
Please help me complete this task.
Thank You,Script all foreign keys that refer to the PK.
Script all nonclustered indexes
Drop all Foreign keys
Drop all nonclustered indexes
Drop the PK
Create the PK as a clustered index
Create the other non-clustered indexes from the earlier script
Create the foreign key references from the earlier script.
Test this at least twice on a development/test environment.
I recently did this on a table with 26 foreign key references. There is no
short cut.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
> How do I convert a primary key field that was created with a non-cluster
> index to a
> cluster index?
> Please help me complete this task.
> Thank You,
>
>|||I believe that you can go from nc to cl for a PK or UQ constraint using CREATE INDEX ... WITH
DROP_EXISTING. It is the other way (cl to nc) that you cannot do using DROP_EXISTING. I'd test it,
but I've been working straight for 15 hours now, so time for some sleep... :-)
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
> Script all foreign keys that refer to the PK.
> Script all nonclustered indexes
> Drop all Foreign keys
> Drop all nonclustered indexes
> Drop the PK
> Create the PK as a clustered index
> Create the other non-clustered indexes from the earlier script
> Create the foreign key references from the earlier script.
> Test this at least twice on a development/test environment.
> I recently did this on a table with 26 foreign key references. There is no short cut.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
> news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
>> How do I convert a primary key field that was created with a non-cluster
>> index to a
>> cluster index?
>> Please help me complete this task.
>> Thank You,
>>
>>
>|||Ahh, come to think about it, the FK's most probably have to be dropped even when using
DROP_EXISTING.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
> Script all foreign keys that refer to the PK.
> Script all nonclustered indexes
> Drop all Foreign keys
> Drop all nonclustered indexes
> Drop the PK
> Create the PK as a clustered index
> Create the other non-clustered indexes from the earlier script
> Create the foreign key references from the earlier script.
> Test this at least twice on a development/test environment.
> I recently did this on a table with 26 foreign key references. There is no short cut.
> --
> Geoff N. Hiten
> Senior Database Administrator
> Microsoft SQL Server MVP
> "Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
> news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
>> How do I convert a primary key field that was created with a non-cluster
>> index to a
>> cluster index?
>> Please help me complete this task.
>> Thank You,
>>
>>
>|||It was from NC to CL that my latest script covered. 26 Foreign Keys.
Arrgh.
--
Geoff N. Hiten
Senior Database Administrator
Microsoft SQL Server MVP
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:umz77K86FHA.2364@.TK2MSFTNGP12.phx.gbl...
>I believe that you can go from nc to cl for a PK or UQ constraint using
>CREATE INDEX ... WITH DROP_EXISTING. It is the other way (cl to nc) that
>you cannot do using DROP_EXISTING. I'd test it, but I've been working
>straight for 15 hours now, so time for some sleep... :-)
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "Geoff N. Hiten" <sqlcraftsman@.gmail.com> wrote in message
> news:uAz8e966FHA.3588@.TK2MSFTNGP15.phx.gbl...
>> Script all foreign keys that refer to the PK.
>> Script all nonclustered indexes
>> Drop all Foreign keys
>> Drop all nonclustered indexes
>> Drop the PK
>> Create the PK as a clustered index
>> Create the other non-clustered indexes from the earlier script
>> Create the foreign key references from the earlier script.
>> Test this at least twice on a development/test environment.
>> I recently did this on a table with 26 foreign key references. There is
>> no short cut.
>> --
>> Geoff N. Hiten
>> Senior Database Administrator
>> Microsoft SQL Server MVP
>> "Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
>> news:764A9F0B-C4EF-4B63-8286-9C15B91870E7@.microsoft.com...
>> How do I convert a primary key field that was created with a non-cluster
>> index to a
>> cluster index?
>> Please help me complete this task.
>> Thank You,
>>
>>
>>
>|||On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
<tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>Ahh, come to think about it, the FK's most probably have to be dropped even when using
>DROP_EXISTING.
But won't the EM do all the voodoo for you?
J.|||> But won't the EM do all the voodoo for you?
Hmm, *without testing*, I bet a beer that EM will drop all foreign keys, drop the index, create the
index and re-create the foreign keys. I doubt that EM is smart enough to execute CREATE INDEX ...
WITH DROP_EXISTING.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"jxstern" <jxstern@.nowhere.xyz> wrote in message news:5ck4o1te08umautq0u1v1l379f8ik3rmlu@.4ax.com...
> On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
> <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>>Ahh, come to think about it, the FK's most probably have to be dropped even when using
>>DROP_EXISTING.
> But won't the EM do all the voodoo for you?
> J.
>|||Your correct, all the Index Tuning Wizard recommends is to drop all indexes
except the cluster index. This is not much help.
What is a good way to analysis tuning indexes?
Thank You,
"Tibor Karaszi" wrote:
> > But won't the EM do all the voodoo for you?
> Hmm, *without testing*, I bet a beer that EM will drop all foreign keys, drop the index, create the
> index and re-create the foreign keys. I doubt that EM is smart enough to execute CREATE INDEX ...
> WITH DROP_EXISTING.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "jxstern" <jxstern@.nowhere.xyz> wrote in message news:5ck4o1te08umautq0u1v1l379f8ik3rmlu@.4ax.com...
> > On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
> > <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
> >>Ahh, come to think about it, the FK's most probably have to be dropped even when using
> >>DROP_EXISTING.
> >
> > But won't the EM do all the voodoo for you?
> >
> > J.
> >
> >
>
>|||> What is a good way to analysis tuning indexes?
IMO, the brain. Know the datamodel, the data and work the query and execution plan. ITW can be some
input, but not a replacement.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
Blog: http://solidqualitylearning.com/blogs/tibor/
"Joe K." <Joe K.@.discussions.microsoft.com> wrote in message
news:514AC714-27B8-424F-9890-261FCE34A769@.microsoft.com...
> Your correct, all the Index Tuning Wizard recommends is to drop all indexes
> except the cluster index. This is not much help.
> What is a good way to analysis tuning indexes?
> Thank You,
>
> "Tibor Karaszi" wrote:
>> > But won't the EM do all the voodoo for you?
>> Hmm, *without testing*, I bet a beer that EM will drop all foreign keys, drop the index, create
>> the
>> index and re-create the foreign keys. I doubt that EM is smart enough to execute CREATE INDEX ...
>> WITH DROP_EXISTING.
>> --
>> Tibor Karaszi, SQL Server MVP
>> http://www.karaszi.com/sqlserver/default.asp
>> http://www.solidqualitylearning.com/
>>
>> "jxstern" <jxstern@.nowhere.xyz> wrote in message
>> news:5ck4o1te08umautq0u1v1l379f8ik3rmlu@.4ax.com...
>> > On Thu, 17 Nov 2005 23:04:33 +0100, "Tibor Karaszi"
>> > <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote:
>> >>Ahh, come to think about it, the FK's most probably have to be dropped even when using
>> >>DROP_EXISTING.
>> >
>> > But won't the EM do all the voodoo for you?
>> >
>> > J.
>> >
>> >
>>