DEFRAG AND DBCC DBREINDEX NOT UPDATING

  • Hello,

    I did all commands posted by the guys on the forum like

    DBCC SHOWCONTIG ('CADCAM')

    sp_updatestats

    DBCC UPDATEUSAGE ('Power','CADCAM')

    DBCC DBREINDEX

    I did the maintanance plan and the Avg. Page Density (full)  is not changing

    - Pages Scanned................................: 1

    - Extents Scanned..............................: 1

    - Extent Switches..............................: 0

    - Avg. Pages per Extent........................: 1.0

    - Scan Density [Best Count:Actual Count].......: 100.00% [1:1]

    - Logical Scan Fragmentation ..................: 0.00%

    - Extent Scan Fragmentation ...................: 0.00%

    - Avg. Bytes Free per Page.....................: 6670.0

    - Avg. Page Density (full).....................: 17.59%

    Someone knows a trick?

     

    Thanks

  • dbcc dbreindex will rebuild your indexes with their original fill factor and this why you will have a low average page density. You find out the original fill factor from the sysnidexes table of the database.

    Anyway if you want a higher page density try dbcc dbreindex and specifya fill factor. e.g.

    DBCC DBREINDEX ('pubs.dbo.authors', UPKCL_auidind, 80)

    this will do it with a fill factor of 80%

    If you need help determining fill factors there a good article on this site.

     

    hth

     

    David

  • Thanks David!

    I know just that if the table is read only, the best choice is to use 100% of fill factor

    Is that true?

    I dont found  the article, do you have the link?

    Thanks again

  • If the table was read only yes you would want a very high fill factor as there will be no updates to that could cause page splitting etc.

    The fill factor you should use depends on how many updates are being made to the table as you want to minimise page splits but you also don't want such a low fill factor that sql server is having to traverse a huge number of extra index pages.

    Anyway here's the link

    http://www.sqlservercentral.com/columnists/jweisbecker/amethodologyfordeterminingfillfactors.asp

     

    To get the original fill factor from sysindexes do something like

    select name, origfillfactor

    from sysindexes

    where name = 'nameofyourindex'

    The default fillfactor is 0 which is similar to 100% but it tries to leave room to insert one row

    hth

    David

  • Hello David,

    I read the article, its very good and very complex....

    Just to begin i will show an example

    I have a table that every day must be truncated its like a stage table...

    And the call center software update and select data every second.

    So the table is 0% FILLFACTOR with these settings:

    - Pages Scanned................................: 1970

    - Extents Scanned..............................: 247

    - Extent Switches..............................: 246

    - Avg. Pages per Extent........................: 8.0

    - Scan Density [Best Count:Actual Count].......: 100.00% [247:247]

    - Logical Scan Fragmentation ..................: 0.00%

    - Extent Scan Fragmentation ...................: 4.05%

    - Avg. Bytes Free per Page.....................: 47.5

    - Avg. Page Density (full).....................: 99.41%

    Have i to increase my fill factor to have a better Page Density?

    Have i to measure the page splits on Sql Server?

    Can you help me with my first steps?

    Thanks dude!

     

  • Yes to get a better page density you have to increase your fill factor.

    You'll be able to tell if you have  alot of page splits by looking at

    Logical Scan Fragmentation ..................: 0.00%

    Extent Scan Fragmentation ...................: 4.05%

     

    these should both be low

     

    hth

    David

  • David

    I was reading an article at Microsoft Msdn website and they wrote:

    If writes are a substantial fraction of reads, the best approach in a very busy OLTP system is to specify as high a FILLFACTOR as feasible that will leave a minimal amount of free space per 8-KB page but still prevent page splitting and still allow the SQL Server to reach the next available time window for rebuilding the index. This methodology balances I/O performance (keeping the pages as full as possible) and page splitting avoidance (not letting pages overflow). This may take some experimentation with rebuilding the index with varying FILLFACTOR and then simulating load activity on the table to validate an optimal value for FILLFACTOR. Once the optimal FILLFACTOR value has been determined, automate the scheduled rebuilding of the index as a SQL Server Task. For More information on automating tasks, search in SQL Server Books Online for the string "creating a task."

    In the situation where there will be no write activity into the SQL Server database, FILLFACTOR should be set at 100 percent so that all index and data pages are filled completely for maximum I/O performance.

     

    So, In my case a have to read a lot of data and sometimes send an update.

    Setting a fillfactor with 70% (I read a lot of data and sometimes i update)  will i increase my index file?

    Do you have any suggestion?

    Thanks

  • If i'm desigining a new database and very little idea about the usage in terms of updates versus reads I usualy start with a fill factor of 95% and then adjust this as necessary pretty much as per the article.

    If however I know that were be a lot of writes I usually start at 90%.

    There is no hard and fast rule on this, the correct fill factor depends on how often you rebuild your indexes and the no of writes versus the number of reads. I wouldn't worry to much if your indexes suffer from a little bit of external fragmentation unless you carry out a lot of index scans i.e. the queries you run against this table use an index scan in their execution plan. In my opinion a bit of external fragmentation is much better than internal fragmentation (Internal fragmentatin just means that the index is a lot bigger than it needs to be because the index pages are not full)

    So in short its a balancing act between leaving enough space in the index pages so that new inserts don't cause page splits between index rebuilds and making sure that the index pages are as full as possible so that the index is not any bigger than it has to be

    hth

     

    David

  • If you set the fill factor at 70%, you would have to scan more pages each time you have to read because the page denisity would be less. It will however, reduce the number of page splits. The best way to determine a fill factor value is to start off at a good approximate value (say 80%) and monitor the number of page splits in perf monitor. If the page splits is high, you can reduce the number to maybe 75 or 70 and monitor the page splits value again.

    To answer the first question that was posted on this thread, you only have data in 1 page. and only 17% of that page is filled. so there is no problem there. (unless Iam missing something)

  • Heh good point shows how much attention I paid to the output of dbcc showcontig didn't even pay attention to the number of pages scanned.

  • For the very first time you have to know some basics:

    dbreindex is not useful if your table is less then a segment (8 pages)

    Also if you do not have clustered index on your table, the table itself wont be defragmented.



    Bye
    Gabor

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

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