Drop Table

Support Forum for database administrators and web based access to important newsgroups related to databases
Register on Database Support Forum Edit your profileCalendarFind other Database Support forum membersFrequently Asked QuestionsSearch this forum -> 
For Database admins: Free Database-related Magazines Now Free shipping to Texas


Post New Thread










Thread
Author

Running updates - the quickest approach - please help.
Hi everyone,

I have to update a column with about 1.34M rows. The column is a a
primary key and hence has a clustered index associated with it. I have
to run updates o nthis column.
Would it be quicker to do the following:

1. Delete the index
2. Run the updates
3. Recreate the index

OR

1. Just run the updates and never mind the index?



Which approach would be faster? Anyone with any
views/comments/suggestions/experience thay would like to share I would
be very much appreciative.

Al.


Report this thread to moderator Post Follow-up to this message
Old Post
almurph@altavista.com
03-01-06 01:23 AM


Re: Running updates - the quickest approach - please help.
A primary key doesn't necessarily have a clustered index.  It can be
nonclustered.  As for the update at hand, it depends.  The index could help
you locate the specific rows you are updating, thus making the query faster.
However, you'll also be updating the index, which will decrease performance.
The only way to tell is to take a copy of the table and run it both ways,
comparing the results.

Can you post your complete DDL + query?

--
Tom

----------------------------------------------------
Thomas A. Moreau, BSc, PhD, MCSE, MCDBA
SQL Server MVP
Columnist, SQL Server Professional
Toronto, ON   Canada
www.pinpub.com
.
<almurph@altavista.com> wrote in message
news:1141040040.741042.9260@i39g2000cwa.googlegroups.com...
Hi everyone,

I have to update a column with about 1.34M rows. The column is a a
primary key and hence has a clustered index associated with it. I have
to run updates o nthis column.
Would it be quicker to do the following:

1. Delete the index
2. Run the updates
3. Recreate the index

OR

1. Just run the updates and never mind the index?



Which approach would be faster? Anyone with any
views/comments/suggestions/experience thay would like to share I would
be very much appreciative.

Al.


Report this thread to moderator Post Follow-up to this message
Old Post
Tom Moreau
03-01-06 01:23 AM


Re: Running updates - the quickest approach - please help.
How about
SET ROWCOUNT 1000
WHILE 1 = 1
BEGIN
---Here is your update statement
IF @@ROWCOUNT = 0
BEGIN
BREAK
END
ELSE
BEGIN

CHECKPOINT
END
END

SET ROWCOUNT 0
<almurph@altavista.com> wrote in message
news:1141040040.741042.9260@i39g2000cwa.googlegroups.com...
> Hi everyone,
>
> I have to update a column with about 1.34M rows. The column is a a
> primary key and hence has a clustered index associated with it. I have
> to run updates o nthis column.
> Would it be quicker to do the following:
>
> 1. Delete the index
> 2. Run the updates
> 3. Recreate the index
>
> OR
>
> 1. Just run the updates and never mind the index?
>
>
>
> Which approach would be faster? Anyone with any
> views/comments/suggestions/experience thay would like to share I would
> be very much appreciative.
>
> Al.
>



Report this thread to moderator Post Follow-up to this message
Old Post
Uri Dimant
03-01-06 01:23 AM


Sponsored Links





Last Thread Next Thread
Post New Thread

MS SQL Server archive

Show a Printable Version Email This Page to Someone! Receive updates to this thread
Microsoft SQL Server
Access database support
PostgreSQL Replication
SQL Server ODBC
FoxPro Support
PostgreSQL pgAdmin
SQL Server Clustering
MySQL ODBC
Web Applications with dBASE
SQL Server CE
MySQL++
Sybase Database Support
MS SQL Full Text Search
PostgreSQL Administration
SQL Anywhere support
DB2 UDB Database
Paradox Database Support
Filemaker Database
Berkley DB
SQL 2000/2000i database
ASE Database
Forum Jump:
All times are GMT. The time now is 10:16 AM.

 
Mobile devices forum | Database support forum archive




Copyrights DropTable.com Database Support Forum 2004 - 2006