Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. Database & SysAdmin
  3. Database
  4. Index Fragmentation in Microsoft SQL Server [modified]

Index Fragmentation in Microsoft SQL Server [modified]

Scheduled Pinned Locked Moved Database
databasesql-serversysadminxmlperformance
2 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Member 2853212
    wrote on last edited by
    #1

    I have a database table that consists of an int primary key, several unique identifiers (most of which are used to reference data in other databases), an xml field and an infoset. I have non-unique, non-clustered indexes that I am trying to use to speed up the queries to the table, all of the indexes work well except for a single index on a uniqueidentifier field that retains a 99% fragmentation rate regardless of rebuild/reorganizing the index. Below is the details of the table, IX_external_guid_3 is the index with the high fragmentation. Can anyone tell me what might cause the high fragmentation, or what I can do to reduce the fragmentation on this guid field and speed up queries based on it? Thanks, Table
    id(PK, int, not null) guid(uniqueidentifier, null, rowguid) external_guid_1(uniqueidentifier, not null) external_guid_2(uniqueidentifier, null) state(varchar(32), null) value(varchar(max), null) infoset(XML(.), null) created_time(datetime, null) updated_time(datetime, null) external_guid_3(uniqueidentifier, not null) FK_id(FK, int, null) locking_guid(uniqueidentifer, null) locked_time(datetime, null) external_guid_4(uniqueidentifier, null) corrected_time(datetime, null) is_add(bit, not null) score(int, null) row_version(timestamp, null) Indexes
    PK_table(Clustered) IX_created_time(Non-Unique, Non-Clustered) IX_external_guid_1(Non-Unique, Non-Clustered) IX_guid(Non-Unique, Non-Clustered) IX_external_guid_3(Non-Unique, Non-Clustered) IX_state(Non-Unique, Non-Clustered)

    John

    modified on Tuesday, December 21, 2010 2:57 PM

    S 1 Reply Last reply
    0
    • M Member 2853212

      I have a database table that consists of an int primary key, several unique identifiers (most of which are used to reference data in other databases), an xml field and an infoset. I have non-unique, non-clustered indexes that I am trying to use to speed up the queries to the table, all of the indexes work well except for a single index on a uniqueidentifier field that retains a 99% fragmentation rate regardless of rebuild/reorganizing the index. Below is the details of the table, IX_external_guid_3 is the index with the high fragmentation. Can anyone tell me what might cause the high fragmentation, or what I can do to reduce the fragmentation on this guid field and speed up queries based on it? Thanks, Table
      id(PK, int, not null) guid(uniqueidentifier, null, rowguid) external_guid_1(uniqueidentifier, not null) external_guid_2(uniqueidentifier, null) state(varchar(32), null) value(varchar(max), null) infoset(XML(.), null) created_time(datetime, null) updated_time(datetime, null) external_guid_3(uniqueidentifier, not null) FK_id(FK, int, null) locking_guid(uniqueidentifer, null) locked_time(datetime, null) external_guid_4(uniqueidentifier, null) corrected_time(datetime, null) is_add(bit, not null) score(int, null) row_version(timestamp, null) Indexes
      PK_table(Clustered) IX_created_time(Non-Unique, Non-Clustered) IX_external_guid_1(Non-Unique, Non-Clustered) IX_guid(Non-Unique, Non-Clustered) IX_external_guid_3(Non-Unique, Non-Clustered) IX_state(Non-Unique, Non-Clustered)

      John

      modified on Tuesday, December 21, 2010 2:57 PM

      S Offline
      S Offline
      ScottM1
      wrote on last edited by
      #2

      I've had a similar problem to this before, rebuilding or reorganizing wouldn't make a difference. I ended up dropping the index and recreating it.

      1 Reply Last reply
      0
      Reply
      • Reply as topic
      Log in to reply
      • Oldest to Newest
      • Newest to Oldest
      • Most Votes


      • Login

      • Don't have an account? Register

      • Login or register to search.
      • First post
        Last post
      0
      • Categories
      • Recent
      • Tags
      • Popular
      • World
      • Users
      • Groups