Results 1 to 9 of 9

Thread: deleting rows

  1. #1
    Join Date
    Nov 2004
    Location
    OHIO
    Posts
    5

    Unanswered: deleting rows

    I have a table with approx 5 million rows and 36 columns. It takes approx
    4 minutes to delete 1 row. The table has 3 indexes in addition to it's primary key and has twelve foreign key constraints. We are still using sequel 7.
    There is a backup run every night as part of the nightly maintenence that
    reorg/reindexes and checks the database integrity. Any thoughts?

    Thanks

  2. #2
    Join Date
    Aug 2004
    Location
    Calgary, Alberta
    Posts
    106
    well I depends what your deleting on. Make sure that you're using an indexed column, and check the execution plan to make sure that it's doing a table seek and not a table scan.

    What are you stats for this table set to ?

  3. #3
    Join Date
    Nov 2004
    Location
    OHIO
    Posts
    5
    I am using a simple delete such as delete from tablename where transsk = 1002
    with transsk being the primary key. This has only become a problem once the table grew over a mil rows.

  4. #4
    Join Date
    Aug 2004
    Location
    Calgary, Alberta
    Posts
    106
    what kind of index, clustered or non-clustered ?

    and did you set a fill factor on the table ?

    setting your index properly should bring down your delete to a few seconds.
    I've got tables that are 6mil+ rows and a delete takes < 15 secs.

  5. #5
    Join Date
    Nov 2004
    Location
    OHIO
    Posts
    5
    The primary key is non-clustered with a fill factor of 90.
    There are also three indexes. Two non-clustered and one clustered, all three with a fill factor of 90. It's also odd to me that inserting rows is not a problem.

  6. #6
    Join Date
    Aug 2004
    Location
    Calgary, Alberta
    Posts
    106
    Inserting a row shouldn't be much of a problem as you don't have to seek to insert a row. If you've got a clustered index, there is a little bit of overhead as the data needs to be arranged logically. IE, it may have to shuffle other rows around to properly fit in the one you are inserting. With a non-clustered index, it can just append the row to the logical group and add an entry into the tree.


    What you may want to try for benchmarking purposes is to remove the clustered index and see if you get a performance increase when inserting or deleting. I don't think you'll get much, but it's worth a shot....

    have you taken a look at the execution plan for a simple delete like the one you posted ?

  7. #7
    Join Date
    Nov 2004
    Location
    OHIO
    Posts
    5
    Thanks, I will give that a try by removing the clustered index.
    Do you have tables with as many foreign key constraints? I didn't know if 12 was a unusually large amount.

    Also, I guess I'm an idiot, what do you mean by execution plan?

  8. #8
    Join Date
    Aug 2004
    Location
    Calgary, Alberta
    Posts
    106
    If you open query analyzer, there is a button at the top that will show you the proposed execution plan that SQL server will use when you run that SQL. The execution plan is created based on statistics.

    Also, I think 12 FK constraints on one table is *a lot*. You should really only have 1 to 3. That's likely the reason it's taking so long to delete anything, it's got many constraints to check before deleting a row.


    Cheers,
    -Kilka

  9. #9
    Join Date
    Nov 2002
    Location
    Jersey
    Posts
    10,322
    Use this sample and apply your own code and cut and paste what it returns

    Code:
    USE Northwind
    GO
    
    SET NOCOUNT ON
    CREATE TABLE myTable99(Col1 int IDENTITY PRIMARY KEY, Col2 char(1))
    GO
    
    INSERT INTO myTable99(Col2)
    SELECT 'A' UNION ALL
    SELECT 'B' UNION ALL
    SELECT 'C'
    GO
    
    SET SHOWPLAN_TEXT ON
    GO
    
    DELETE FROM myTable99 WHERE Col1 = 2
    GO
    
    SET SHOWPLAN_TEXT OFF
    GO
    
    SET NOCOUNT OFF
    DROP TABLE myTable99
    GO
    Brett
    8-)

    It's a Great Day for America everybody!

    dbforums Yak CorralRadio 'Rita
    dbForums Member List
    I'm Good Once as I ever was

    The physical order of data in a database has no meaning.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •