Showing posts with label fragmentation. Show all posts
Showing posts with label fragmentation. Show all posts

Saturday, February 25, 2012

dbreindex causes fragmentation in other indexes

We have a report that uses dbcc showcontig to identify indexes with
fragmentation. It shows indexes that have a scan density under 85% or extent
fragmentation over 15%. I run dbcc dbreindex against the indexes identified
in the report to rebuild the indexes. When I run the report again a
completely different index shows up. During this time no other users or
processes are running against the database. Any ideas what may be causing
this?
--
OdellHi
You may want to build all indexes for the given table rather than specific
index, especially if the index is a clustered.
John
"Odell Edwards" wrote:
> We have a report that uses dbcc showcontig to identify indexes with
> fragmentation. It shows indexes that have a scan density under 85% or extent
> fragmentation over 15%. I run dbcc dbreindex against the indexes identified
> in the report to rebuild the indexes. When I run the report again a
> completely different index shows up. During this time no other users or
> processes are running against the database. Any ideas what may be causing
> this?
> --
> Odell|||Thanks for the post. We tried rebuilding all the indexes. It took several
hours but it didn't clean up the fragmentation.
--
Odell
"John Bell" wrote:
> Hi
> You may want to build all indexes for the given table rather than specific
> index, especially if the index is a clustered.
> John
> "Odell Edwards" wrote:
> > We have a report that uses dbcc showcontig to identify indexes with
> > fragmentation. It shows indexes that have a scan density under 85% or extent
> > fragmentation over 15%. I run dbcc dbreindex against the indexes identified
> > in the report to rebuild the indexes. When I run the report again a
> > completely different index shows up. During this time no other users or
> > processes are running against the database. Any ideas what may be causing
> > this?
> > --
> > Odell|||Hi
Did you specify the indexes individually or just the table?
John
"Odell Edwards" wrote:
> Thanks for the post. We tried rebuilding all the indexes. It took several
> hours but it didn't clean up the fragmentation.
> --
> Odell
>
> "John Bell" wrote:
> > Hi
> >
> > You may want to build all indexes for the given table rather than specific
> > index, especially if the index is a clustered.
> >
> > John
> >
> > "Odell Edwards" wrote:
> >
> > > We have a report that uses dbcc showcontig to identify indexes with
> > > fragmentation. It shows indexes that have a scan density under 85% or extent
> > > fragmentation over 15%. I run dbcc dbreindex against the indexes identified
> > > in the report to rebuild the indexes. When I run the report again a
> > > completely different index shows up. During this time no other users or
> > > processes are running against the database. Any ideas what may be causing
> > > this?
> > > --
> > > Odell|||We sepcified the table, not the individual indexes.
--
Odell
"John Bell" wrote:
> Hi
> Did you specify the indexes individually or just the table?
> John
> "Odell Edwards" wrote:
> > Thanks for the post. We tried rebuilding all the indexes. It took several
> > hours but it didn't clean up the fragmentation.
> > --
> > Odell
> >
> >
> > "John Bell" wrote:
> >
> > > Hi
> > >
> > > You may want to build all indexes for the given table rather than specific
> > > index, especially if the index is a clustered.
> > >
> > > John
> > >
> > > "Odell Edwards" wrote:
> > >
> > > > We have a report that uses dbcc showcontig to identify indexes with
> > > > fragmentation. It shows indexes that have a scan density under 85% or extent
> > > > fragmentation over 15%. I run dbcc dbreindex against the indexes identified
> > > > in the report to rebuild the indexes. When I run the report again a
> > > > completely different index shows up. During this time no other users or
> > > > processes are running against the database. Any ideas what may be causing
> > > > this?
> > > > --
> > > > Odell|||This is the format we used
dbcc dbreindex (<tablename>, '',0)
Thanks,
--
Odell
"Odell Edwards" wrote:
> We sepcified the table, not the individual indexes.
> --
> Odell
>
> "John Bell" wrote:
> > Hi
> >
> > Did you specify the indexes individually or just the table?
> >
> > John
> >
> > "Odell Edwards" wrote:
> >
> > > Thanks for the post. We tried rebuilding all the indexes. It took several
> > > hours but it didn't clean up the fragmentation.
> > > --
> > > Odell
> > >
> > >
> > > "John Bell" wrote:
> > >
> > > > Hi
> > > >
> > > > You may want to build all indexes for the given table rather than specific
> > > > index, especially if the index is a clustered.
> > > >
> > > > John
> > > >
> > > > "Odell Edwards" wrote:
> > > >
> > > > > We have a report that uses dbcc showcontig to identify indexes with
> > > > > fragmentation. It shows indexes that have a scan density under 85% or extent
> > > > > fragmentation over 15%. I run dbcc dbreindex against the indexes identified
> > > > > in the report to rebuild the indexes. When I run the report again a
> > > > > completely different index shows up. During this time no other users or
> > > > > processes are running against the database. Any ideas what may be causing
> > > > > this?
> > > > > --
> > > > > Odell|||Scan density is meaningless if you have several database files (search the archives). And there's
little you can do about extent scan fragmentation (I tend to ignore it). Look at Logical
fragmentation...
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Odell Edwards" <OdellEdwards@.discussions.microsoft.com> wrote in message
news:74893251-4530-4105-BAEA-B99923C81693@.microsoft.com...
> This is the format we used
> dbcc dbreindex (<tablename>, '',0)
> Thanks,
> --
> Odell
>
> "Odell Edwards" wrote:
>> We sepcified the table, not the individual indexes.
>> --
>> Odell
>>
>> "John Bell" wrote:
>> > Hi
>> >
>> > Did you specify the indexes individually or just the table?
>> >
>> > John
>> >
>> > "Odell Edwards" wrote:
>> >
>> > > Thanks for the post. We tried rebuilding all the indexes. It took several
>> > > hours but it didn't clean up the fragmentation.
>> > > --
>> > > Odell
>> > >
>> > >
>> > > "John Bell" wrote:
>> > >
>> > > > Hi
>> > > >
>> > > > You may want to build all indexes for the given table rather than specific
>> > > > index, especially if the index is a clustered.
>> > > >
>> > > > John
>> > > >
>> > > > "Odell Edwards" wrote:
>> > > >
>> > > > > We have a report that uses dbcc showcontig to identify indexes with
>> > > > > fragmentation. It shows indexes that have a scan density under 85% or extent
>> > > > > fragmentation over 15%. I run dbcc dbreindex against the indexes identified
>> > > > > in the report to rebuild the indexes. When I run the report again a
>> > > > > completely different index shows up. During this time no other users or
>> > > > > processes are running against the database. Any ideas what may be causing
>> > > > > this?
>> > > > > --
>> > > > > Odell|||Is this a clustered index or a HEAP? If it is a HEAP then you can reindex
all you want and nothing will happen to reduce fragmentation. Can you post
the results of DBCC SHOWCONTIG?
--
Andrew J. Kelly SQL MVP
"Odell Edwards" <OdellEdwards@.discussions.microsoft.com> wrote in message
news:74893251-4530-4105-BAEA-B99923C81693@.microsoft.com...
> This is the format we used
> dbcc dbreindex (<tablename>, '',0)
> Thanks,
> --
> Odell
>
> "Odell Edwards" wrote:
>> We sepcified the table, not the individual indexes.
>> --
>> Odell
>>
>> "John Bell" wrote:
>> > Hi
>> >
>> > Did you specify the indexes individually or just the table?
>> >
>> > John
>> >
>> > "Odell Edwards" wrote:
>> >
>> > > Thanks for the post. We tried rebuilding all the indexes. It took
>> > > several
>> > > hours but it didn't clean up the fragmentation.
>> > > --
>> > > Odell
>> > >
>> > >
>> > > "John Bell" wrote:
>> > >
>> > > > Hi
>> > > >
>> > > > You may want to build all indexes for the given table rather than
>> > > > specific
>> > > > index, especially if the index is a clustered.
>> > > >
>> > > > John
>> > > >
>> > > > "Odell Edwards" wrote:
>> > > >
>> > > > > We have a report that uses dbcc showcontig to identify indexes
>> > > > > with
>> > > > > fragmentation. It shows indexes that have a scan density under
>> > > > > 85% or extent
>> > > > > fragmentation over 15%. I run dbcc dbreindex against the indexes
>> > > > > identified
>> > > > > in the report to rebuild the indexes. When I run the report
>> > > > > again a
>> > > > > completely different index shows up. During this time no other
>> > > > > users or
>> > > > > processes are running against the database. Any ideas what may
>> > > > > be causing
>> > > > > this?
>> > > > > --
>> > > > > Odell

dbreindex causes fragmentation in other indexes

We have a report that uses dbcc showcontig to identify indexes with
fragmentation. It shows indexes that have a scan density under 85% or exten
t
fragmentation over 15%. I run dbcc dbreindex against the indexes identified
in the report to rebuild the indexes. When I run the report again a
completely different index shows up. During this time no other users or
processes are running against the database. Any ideas what may be causing
this?
--
OdellHi
You may want to build all indexes for the given table rather than specific
index, especially if the index is a clustered.
John
"Odell Edwards" wrote:

> We have a report that uses dbcc showcontig to identify indexes with
> fragmentation. It shows indexes that have a scan density under 85% or ext
ent
> fragmentation over 15%. I run dbcc dbreindex against the indexes identifi
ed
> in the report to rebuild the indexes. When I run the report again a
> completely different index shows up. During this time no other users or
> processes are running against the database. Any ideas what may be causing
> this?
> --
> Odell|||Thanks for the post. We tried rebuilding all the indexes. It took several
hours but it didn't clean up the fragmentation.
--
Odell
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> You may want to build all indexes for the given table rather than specific
> index, especially if the index is a clustered.
> John
> "Odell Edwards" wrote:
>|||Hi
Did you specify the indexes individually or just the table?
John
"Odell Edwards" wrote:
[vbcol=seagreen]
> Thanks for the post. We tried rebuilding all the indexes. It took several
> hours but it didn't clean up the fragmentation.
> --
> Odell
>
> "John Bell" wrote:
>|||We sepcified the table, not the individual indexes.
--
Odell
"John Bell" wrote:
[vbcol=seagreen]
> Hi
> Did you specify the indexes individually or just the table?
> John
> "Odell Edwards" wrote:
>|||This is the format we used
dbcc dbreindex (<tablename>, '',0)
Thanks,
--
Odell
"Odell Edwards" wrote:
[vbcol=seagreen]
> We sepcified the table, not the individual indexes.
> --
> Odell
>
> "John Bell" wrote:
>|||Scan density is meaningless if you have several database files (search the a
rchives). And there's
little you can do about extent scan fragmentation (I tend to ignore it). Loo
k at Logical
fragmentation...
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Odell Edwards" <OdellEdwards@.discussions.microsoft.com> wrote in message
news:74893251-4530-4105-BAEA-B99923C81693@.microsoft.com...[vbcol=seagreen]
> This is the format we used
> dbcc dbreindex (<tablename>, '',0)
> Thanks,
> --
> Odell
>
> "Odell Edwards" wrote:
>|||Is this a clustered index or a HEAP? If it is a HEAP then you can reindex
all you want and nothing will happen to reduce fragmentation. Can you post
the results of DBCC SHOWCONTIG?
Andrew J. Kelly SQL MVP
"Odell Edwards" <OdellEdwards@.discussions.microsoft.com> wrote in message
news:74893251-4530-4105-BAEA-B99923C81693@.microsoft.com...[vbcol=seagreen]
> This is the format we used
> dbcc dbreindex (<tablename>, '',0)
> Thanks,
> --
> Odell
>
> "Odell Edwards" wrote:
>

DBREINDEX at threshold for all databases

There is a proc in Books Online that allows you to execute a INDEXDEFRAG on
all indexes in a database that have a logical fragmentation percentage above
a specific limit. IT useds SHOWCONTIG and a temporary table. I want to run
this proc with DBREINDEX instead and I want to schedule it wly for all
exising user databases. (The Database Maintenance Wizard is too
inefficient.) If a new database gets added to the environment, I want the
proc to dynamically pick up that new database.
The problem is that this proc has to be executed within the database to be
defragged. I'm having trouble modifying it to loop for each existing
database.
I've tried some "EXEC ('USE ' + @.dbname + ' DBCC SHOW..." but am still
having some problems. This is probably a pretty basic type of maintenance
procedure. Does anyone already have this coded that they would share?I actually have something that may work for you - but not without a little
work. I was trying to do the same thing - a wly job that would run on an
y
existing user db's. If you run this, it will pick up all user databases. I
use PRINT @.SQL instead of EXEC because I was unable to get it to execute the
DBREINDEX without error. And right now I'm taking the results of that and
driving the job. If you're able to get around that, please advise.
DECLARE @.SQL NVarchar(4000)
SET @.SQL = ''
SELECT @.SQL = @.SQL + 'EXEC ' + NAME + '..sp_MSforeachtable @.command1=''DBCC
DBREINDEX (''''*'''')'', @.replacechar=''*''' + Char(13)
FROM MASTER..Sysdatabases
WHERE dbid >6
PRINT @.SQL
-- Lynn
"Stephanie" wrote:

> There is a proc in Books Online that allows you to execute a INDEXDEFRAG o
n
> all indexes in a database that have a logical fragmentation percentage abo
ve
> a specific limit. IT useds SHOWCONTIG and a temporary table. I want to r
un
> this proc with DBREINDEX instead and I want to schedule it wly for all
> exising user databases. (The Database Maintenance Wizard is too
> inefficient.) If a new database gets added to the environment, I want the
> proc to dynamically pick up that new database.
> The problem is that this proc has to be executed within the database to be
> defragged. I'm having trouble modifying it to loop for each existing
> database.
> I've tried some "EXEC ('USE ' + @.dbname + ' DBCC SHOW..." but am still
> having some problems. This is probably a pretty basic type of maintenance
> procedure. Does anyone already have this coded that they would share?
>|||Maybe this helps:
http://milambda.blogspot.com/2005/0...in-current.html
It needs a wrapper that will execute it for each database, and you need to
propagate the db_id value through to the dbcc call (currently the value of
db_id is 0 - current database).
ML