Does anyone know where I can see the source SQL for this View?
OR
Does anyone know which fields in which system tables would allow me to
determine whether updates and deletes are cascaded?
> Does anyone know where I can see the source SQL for this View?
EXEC master..sp_helptext 'INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS'
> Does anyone know which fields in which system tables would allow me to
> determine whether updates and deletes are cascaded?
You can also get the cascade options using SQL Server OBJECTPROPERTY
functions.
Hope this helps.
Dan Guzman
SQL Server MVP
"cathedr@.wa.state.gov" <cathedrwastategov@.discussions.microsoft.com> wrote
in message news:3C2F64CC-DA03-4FE2-B198-E76DDB203BE1@.microsoft.com...
> Does anyone know where I can see the source SQL for this View?
> OR
> Does anyone know which fields in which system tables would allow me to
> determine whether updates and deletes are cascaded?
Showing posts with label system. Show all posts
Showing posts with label system. Show all posts
Friday, March 30, 2012
INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS
Does anyone know where I can see the source SQL for this View?
OR
Does anyone know which fields in which system tables would allow me to
determine whether updates and deletes are cascaded?> Does anyone know where I can see the source SQL for this View?
EXEC master..sp_helptext 'INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS'
> Does anyone know which fields in which system tables would allow me to
> determine whether updates and deletes are cascaded?
You can also get the cascade options using SQL Server OBJECTPROPERTY
functions.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"cathedr@.wa.state.gov" <cathedrwastategov@.discussions.microsoft.com> wrote
in message news:3C2F64CC-DA03-4FE2-B198-E76DDB203BE1@.microsoft.com...
> Does anyone know where I can see the source SQL for this View?
> OR
> Does anyone know which fields in which system tables would allow me to
> determine whether updates and deletes are cascaded?
OR
Does anyone know which fields in which system tables would allow me to
determine whether updates and deletes are cascaded?> Does anyone know where I can see the source SQL for this View?
EXEC master..sp_helptext 'INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS'
> Does anyone know which fields in which system tables would allow me to
> determine whether updates and deletes are cascaded?
You can also get the cascade options using SQL Server OBJECTPROPERTY
functions.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"cathedr@.wa.state.gov" <cathedrwastategov@.discussions.microsoft.com> wrote
in message news:3C2F64CC-DA03-4FE2-B198-E76DDB203BE1@.microsoft.com...
> Does anyone know where I can see the source SQL for this View?
> OR
> Does anyone know which fields in which system tables would allow me to
> determine whether updates and deletes are cascaded?
INFORMATION_SCHEMA.PARAMETERS
Is anybody able to access system tables used by INFORMATION_SCHEMA.PARAMETERS?
Namely: sys.sysscalartypes, sys.sysschobjs and sys.syscolpars.
A select on any of these failes with 'Invalid object name'
These are system base tables that are used by the database engine only.
Please see http://msdn2.microsoft.com/en-us/library/ms179503.aspx
Is there a reason why you would want to access these base tables ?
|||Curiosity really...INFORMATION_SCHEMA.PARAMETERS
Is anybody able to access system tables used by INFORMATION_SCHEMA.PARAMETERS?
Namely: sys.sysscalartypes, sys.sysschobjs and sys.syscolpars.
A select on any of these failes with 'Invalid object name'
These are system base tables that are used by the database engine only.
Please see http://msdn2.microsoft.com/en-us/library/ms179503.aspx
Is there a reason why you would want to access these base tables ?
|||Curiosity really...
Wednesday, March 28, 2012
INFO/SUGGESTIONS Please : SQL performance (fragmented disk)
I'm a developer at my company, but I've worked with hardware quite abit at my last job. I'm finding it hard to talk to one of our system admins here.
I'm running into what looks like disk issues on our SQL Server, I know the DB files all reside on a large SCSI Raid, the only files on the RAID are the DB files, no OS or program files.
Also the disks have never been defragmented, he wants to say :
1. SCSI and RAID eliminate the impact of fragmentation.
2. SQL doesn't get impacted by physical fragmentation.
I know both to be false statements but don't want to start an argument, nor go over his head.
I would like to "find" some reputable articles dealing with disk fragmentation and SQL(database) performance..
If anyone has a good site that displays good information I would greatly appreciate it.
OR
If anyone has some personal experience with issues like this, please share them..
You may want to read the following white paper: 'Microsoft SQL Server 2000 Index Defragmentation Best Practices' (http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx), which may give you more idea about fragmentation.
Thanks
Stephen
Monday, March 26, 2012
INFO Requested Distributed DB Design
I am in a Process of designing database deployment layout for a system.
There are 4 major subsystem in the application each uses its own database.
Database :
1) Primary DB
2) Processing A DB
3) Reporting DB
4) Processing B DB
The Purpose of Primary is to hold all the Input data in unmodified state.
Processing A DB is a Exact copy of Primary DB.
In Processing A DB the the computation & Validation happens .The Results (
More than one Table )of Processing A is updated in Primary DB.
This Updates needs to be transfered to Reporting DB , Processing B DB.
In Processing B DB some status column is updated and this Updates needs
to be propogated back to the Primary
I am Looking at transactional Replication as a Option for this . Let me
know your views on this
You are trying to do work flow. Replication is not an easy fit with this.
Basically with a replication solution you need a server which will act as
the clearing house figuring out what goes where. With sql2000 you do not
have this - with SQL 2005 you sort of do with the peer to peer replication
model with transactional replication.
It seems that your data flow is this
Primary -> Processing A -> Reporting
-> Processing B -> Primary
Primary <- (with filtering) Processing A
By what criteria does data flow from Processing A back to Primary and how
are you going to prevent data from Processing B flowing back to Processing
A?
If you can filter this data, you could use transactional replication from
one node to another. If you can't I don't think transactional replication
will be a good fit.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:DF063537-EE93-4742-AFBB-8BBAF557CEE4@.microsoft.com...
> I am in a Process of designing database deployment layout for a system.
> There are 4 major subsystem in the application each uses its own
database.
> Database :
> 1) Primary DB
> 2) Processing A DB
> 3) Reporting DB
> 4) Processing B DB
>
> The Purpose of Primary is to hold all the Input data in unmodified
state.
> Processing A DB is a Exact copy of Primary DB.
> In Processing A DB the the computation & Validation happens .The Results (
> More than one Table )of Processing A is updated in Primary DB.
> This Updates needs to be transfered to Reporting DB , Processing B DB.
> In Processing B DB some status column is updated and this Updates needs
> to be propogated back to the Primary
> I am Looking at transactional Replication as a Option for this . Let me
> know your views on this
>
|||Thanks for your response.
Well I have a Status Column on the Primary field based on which i Push the
(Set of tables) data to the Processing A DB .
Process A DB does some computation and Updates Data & the staus field on th
Tables .
My Question is whats the Best way of Pushing this data back(from Processing
A) to the Primary server .
There are around 30 table which gets updated .
I am currently looking at DTS/ Transactional Replication to move the
tables back to the Primay DB. I feel there would be Cyclic Updates ?
any advice on this
Best Reagrds
"Hilary Cotter" wrote:
> You are trying to do work flow. Replication is not an easy fit with this.
> Basically with a replication solution you need a server which will act as
> the clearing house figuring out what goes where. With sql2000 you do not
> have this - with SQL 2005 you sort of do with the peer to peer replication
> model with transactional replication.
> It seems that your data flow is this
> Primary -> Processing A -> Reporting
> -> Processing B -> Primary
> Primary <- (with filtering) Processing A
> By what criteria does data flow from Processing A back to Primary and how
> are you going to prevent data from Processing B flowing back to Processing
> A?
> If you can filter this data, you could use transactional replication from
> one node to another. If you can't I don't think transactional replication
> will be a good fit.
>
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Raaj" <Raaj@.discussions.microsoft.com> wrote in message
> news:DF063537-EE93-4742-AFBB-8BBAF557CEE4@.microsoft.com...
> database.
> state.
>
>
|||I think you want to replicate these tables back, but ensure that the
replication stored procedures have logic built in them to only execute is
the status column is an update.
For instance going from primary to processing a the status column might have
a value of 0, when processed on A it is updated to 1.
In your update replication procs have a wrapper which looks like this going
back to Primary.
if StatusColumn=1 then
do work
else
return 0
In your update replication procs have a wrapper which looks like this going
to PRocessing A.
if StatusColumn=0 then
do work
else
return 0
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:2242A1DF-2047-4C2B-A8F6-A63835767DF5@.microsoft.com...
> Thanks for your response.
> Well I have a Status Column on the Primary field based on which i Push the
> (Set of tables) data to the Processing A DB .
> Process A DB does some computation and Updates Data & the staus field on
th
> Tables .
> My Question is whats the Best way of Pushing this data back(from
Processing[vbcol=seagreen]
> A) to the Primary server .
> There are around 30 table which gets updated .
> I am currently looking at DTS/ Transactional Replication to move the
> tables back to the Primay DB. I feel there would be Cyclic Updates ?
> any advice on this
> Best Reagrds
>
> "Hilary Cotter" wrote:
this.[vbcol=seagreen]
as[vbcol=seagreen]
replication[vbcol=seagreen]
how[vbcol=seagreen]
Processing[vbcol=seagreen]
from[vbcol=seagreen]
replication[vbcol=seagreen]
system.[vbcol=seagreen]
Results ([vbcol=seagreen]
DB.[vbcol=seagreen]
needs[vbcol=seagreen]
me[vbcol=seagreen]
|||Thanks Hilary
Well I have not yet decided on the mechanism to updating the data back to
primary
Server .
I am considering to create a Publication on the Processing A server and
let Primary server subscribe this datas ( seems to me a cyclic and bit over
head) .
Note : there will be more that 30 table updates which needs to be send
back-forth
do you have any suggesstion
"Hilary Cotter" wrote:
> I think you want to replicate these tables back, but ensure that the
> replication stored procedures have logic built in them to only execute is
> the status column is an update.
> For instance going from primary to processing a the status column might have
> a value of 0, when processed on A it is updated to 1.
> In your update replication procs have a wrapper which looks like this going
> back to Primary.
> if StatusColumn=1 then
> do work
> else
> return 0
> In your update replication procs have a wrapper which looks like this going
> to PRocessing A.
> if StatusColumn=0 then
> do work
> else
> return 0
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Raaj" <Raaj@.discussions.microsoft.com> wrote in message
> news:2242A1DF-2047-4C2B-A8F6-A63835767DF5@.microsoft.com...
> th
> Processing
> this.
> as
> replication
> how
> Processing
> from
> replication
> system.
> Results (
> DB.
> needs
> me
>
>
|||it will be cyclic unless you can figure out some criteria to use as a basis
for not applying the transaction. Use this criteria as a basis as to whether
the proc applies the data on the subscriber/publisher or not.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:127378BB-BBAB-4F77-9A10-817170920414@.microsoft.com...
> Thanks Hilary
> Well I have not yet decided on the mechanism to updating the data back to
> primary
> Server .
> I am considering to create a Publication on the Processing A server and
> let Primary server subscribe this datas ( seems to me a cyclic and bit
over[vbcol=seagreen]
> head) .
> Note : there will be more that 30 table updates which needs to be send
> back-forth
> do you have any suggesstion
>
> "Hilary Cotter" wrote:
is[vbcol=seagreen]
have[vbcol=seagreen]
going[vbcol=seagreen]
going[vbcol=seagreen]
the[vbcol=seagreen]
on[vbcol=seagreen]
?[vbcol=seagreen]
act[vbcol=seagreen]
not[vbcol=seagreen]
and[vbcol=seagreen]
unmodified[vbcol=seagreen]
B[vbcol=seagreen]
Updates[vbcol=seagreen]
Let[vbcol=seagreen]
|||Thanks for the info .
Can you please suggest me a mechanism for updatating the data back to the
primary server from the Processing A DB .
I am planning to use replication from Processing A back to the primary
server ... any suggestion here
Raj
"Hilary Cotter" wrote:
> it will be cyclic unless you can figure out some criteria to use as a basis
> for not applying the transaction. Use this criteria as a basis as to whether
> the proc applies the data on the subscriber/publisher or not.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Raaj" <Raaj@.discussions.microsoft.com> wrote in message
> news:127378BB-BBAB-4F77-9A10-817170920414@.microsoft.com...
> over
> is
> have
> going
> going
> the
> on
> ?
> act
> not
> and
> unmodified
> B
> Updates
> Let
>
>
|||replication with custom stored procedures.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:501BF2AB-FF83-4EE4-9927-F80606684F85@.microsoft.com...[vbcol=seagreen]
> Thanks for the info .
> Can you please suggest me a mechanism for updatating the data back to the
> primary server from the Processing A DB .
> I am planning to use replication from Processing A back to the primary
> server ... any suggestion here
> Raj
> "Hilary Cotter" wrote:
basis[vbcol=seagreen]
whether[vbcol=seagreen]
back to[vbcol=seagreen]
and[vbcol=seagreen]
bit[vbcol=seagreen]
execute[vbcol=seagreen]
might[vbcol=seagreen]
this[vbcol=seagreen]
this[vbcol=seagreen]
Push[vbcol=seagreen]
field[vbcol=seagreen]
the[vbcol=seagreen]
Updates[vbcol=seagreen]
with[vbcol=seagreen]
will[vbcol=seagreen]
you do[vbcol=seagreen]
Primary[vbcol=seagreen]
Primary[vbcol=seagreen]
replication[vbcol=seagreen]
for a[vbcol=seagreen]
own[vbcol=seagreen]
..The[vbcol=seagreen]
DB.[vbcol=seagreen]
Processing[vbcol=seagreen]
this .[vbcol=seagreen]
There are 4 major subsystem in the application each uses its own database.
Database :
1) Primary DB
2) Processing A DB
3) Reporting DB
4) Processing B DB
The Purpose of Primary is to hold all the Input data in unmodified state.
Processing A DB is a Exact copy of Primary DB.
In Processing A DB the the computation & Validation happens .The Results (
More than one Table )of Processing A is updated in Primary DB.
This Updates needs to be transfered to Reporting DB , Processing B DB.
In Processing B DB some status column is updated and this Updates needs
to be propogated back to the Primary
I am Looking at transactional Replication as a Option for this . Let me
know your views on this
You are trying to do work flow. Replication is not an easy fit with this.
Basically with a replication solution you need a server which will act as
the clearing house figuring out what goes where. With sql2000 you do not
have this - with SQL 2005 you sort of do with the peer to peer replication
model with transactional replication.
It seems that your data flow is this
Primary -> Processing A -> Reporting
-> Processing B -> Primary
Primary <- (with filtering) Processing A
By what criteria does data flow from Processing A back to Primary and how
are you going to prevent data from Processing B flowing back to Processing
A?
If you can filter this data, you could use transactional replication from
one node to another. If you can't I don't think transactional replication
will be a good fit.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:DF063537-EE93-4742-AFBB-8BBAF557CEE4@.microsoft.com...
> I am in a Process of designing database deployment layout for a system.
> There are 4 major subsystem in the application each uses its own
database.
> Database :
> 1) Primary DB
> 2) Processing A DB
> 3) Reporting DB
> 4) Processing B DB
>
> The Purpose of Primary is to hold all the Input data in unmodified
state.
> Processing A DB is a Exact copy of Primary DB.
> In Processing A DB the the computation & Validation happens .The Results (
> More than one Table )of Processing A is updated in Primary DB.
> This Updates needs to be transfered to Reporting DB , Processing B DB.
> In Processing B DB some status column is updated and this Updates needs
> to be propogated back to the Primary
> I am Looking at transactional Replication as a Option for this . Let me
> know your views on this
>
|||Thanks for your response.
Well I have a Status Column on the Primary field based on which i Push the
(Set of tables) data to the Processing A DB .
Process A DB does some computation and Updates Data & the staus field on th
Tables .
My Question is whats the Best way of Pushing this data back(from Processing
A) to the Primary server .
There are around 30 table which gets updated .
I am currently looking at DTS/ Transactional Replication to move the
tables back to the Primay DB. I feel there would be Cyclic Updates ?
any advice on this
Best Reagrds
"Hilary Cotter" wrote:
> You are trying to do work flow. Replication is not an easy fit with this.
> Basically with a replication solution you need a server which will act as
> the clearing house figuring out what goes where. With sql2000 you do not
> have this - with SQL 2005 you sort of do with the peer to peer replication
> model with transactional replication.
> It seems that your data flow is this
> Primary -> Processing A -> Reporting
> -> Processing B -> Primary
> Primary <- (with filtering) Processing A
> By what criteria does data flow from Processing A back to Primary and how
> are you going to prevent data from Processing B flowing back to Processing
> A?
> If you can filter this data, you could use transactional replication from
> one node to another. If you can't I don't think transactional replication
> will be a good fit.
>
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Raaj" <Raaj@.discussions.microsoft.com> wrote in message
> news:DF063537-EE93-4742-AFBB-8BBAF557CEE4@.microsoft.com...
> database.
> state.
>
>
|||I think you want to replicate these tables back, but ensure that the
replication stored procedures have logic built in them to only execute is
the status column is an update.
For instance going from primary to processing a the status column might have
a value of 0, when processed on A it is updated to 1.
In your update replication procs have a wrapper which looks like this going
back to Primary.
if StatusColumn=1 then
do work
else
return 0
In your update replication procs have a wrapper which looks like this going
to PRocessing A.
if StatusColumn=0 then
do work
else
return 0
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:2242A1DF-2047-4C2B-A8F6-A63835767DF5@.microsoft.com...
> Thanks for your response.
> Well I have a Status Column on the Primary field based on which i Push the
> (Set of tables) data to the Processing A DB .
> Process A DB does some computation and Updates Data & the staus field on
th
> Tables .
> My Question is whats the Best way of Pushing this data back(from
Processing[vbcol=seagreen]
> A) to the Primary server .
> There are around 30 table which gets updated .
> I am currently looking at DTS/ Transactional Replication to move the
> tables back to the Primay DB. I feel there would be Cyclic Updates ?
> any advice on this
> Best Reagrds
>
> "Hilary Cotter" wrote:
this.[vbcol=seagreen]
as[vbcol=seagreen]
replication[vbcol=seagreen]
how[vbcol=seagreen]
Processing[vbcol=seagreen]
from[vbcol=seagreen]
replication[vbcol=seagreen]
system.[vbcol=seagreen]
Results ([vbcol=seagreen]
DB.[vbcol=seagreen]
needs[vbcol=seagreen]
me[vbcol=seagreen]
|||Thanks Hilary
Well I have not yet decided on the mechanism to updating the data back to
primary
Server .
I am considering to create a Publication on the Processing A server and
let Primary server subscribe this datas ( seems to me a cyclic and bit over
head) .
Note : there will be more that 30 table updates which needs to be send
back-forth
do you have any suggesstion
"Hilary Cotter" wrote:
> I think you want to replicate these tables back, but ensure that the
> replication stored procedures have logic built in them to only execute is
> the status column is an update.
> For instance going from primary to processing a the status column might have
> a value of 0, when processed on A it is updated to 1.
> In your update replication procs have a wrapper which looks like this going
> back to Primary.
> if StatusColumn=1 then
> do work
> else
> return 0
> In your update replication procs have a wrapper which looks like this going
> to PRocessing A.
> if StatusColumn=0 then
> do work
> else
> return 0
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Raaj" <Raaj@.discussions.microsoft.com> wrote in message
> news:2242A1DF-2047-4C2B-A8F6-A63835767DF5@.microsoft.com...
> th
> Processing
> this.
> as
> replication
> how
> Processing
> from
> replication
> system.
> Results (
> DB.
> needs
> me
>
>
|||it will be cyclic unless you can figure out some criteria to use as a basis
for not applying the transaction. Use this criteria as a basis as to whether
the proc applies the data on the subscriber/publisher or not.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:127378BB-BBAB-4F77-9A10-817170920414@.microsoft.com...
> Thanks Hilary
> Well I have not yet decided on the mechanism to updating the data back to
> primary
> Server .
> I am considering to create a Publication on the Processing A server and
> let Primary server subscribe this datas ( seems to me a cyclic and bit
over[vbcol=seagreen]
> head) .
> Note : there will be more that 30 table updates which needs to be send
> back-forth
> do you have any suggesstion
>
> "Hilary Cotter" wrote:
is[vbcol=seagreen]
have[vbcol=seagreen]
going[vbcol=seagreen]
going[vbcol=seagreen]
the[vbcol=seagreen]
on[vbcol=seagreen]
?[vbcol=seagreen]
act[vbcol=seagreen]
not[vbcol=seagreen]
and[vbcol=seagreen]
unmodified[vbcol=seagreen]
B[vbcol=seagreen]
Updates[vbcol=seagreen]
Let[vbcol=seagreen]
|||Thanks for the info .
Can you please suggest me a mechanism for updatating the data back to the
primary server from the Processing A DB .
I am planning to use replication from Processing A back to the primary
server ... any suggestion here
Raj
"Hilary Cotter" wrote:
> it will be cyclic unless you can figure out some criteria to use as a basis
> for not applying the transaction. Use this criteria as a basis as to whether
> the proc applies the data on the subscriber/publisher or not.
> --
> Hilary Cotter
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
> Looking for a FAQ on Indexing Services/SQL FTS
> http://www.indexserverfaq.com
> "Raaj" <Raaj@.discussions.microsoft.com> wrote in message
> news:127378BB-BBAB-4F77-9A10-817170920414@.microsoft.com...
> over
> is
> have
> going
> going
> the
> on
> ?
> act
> not
> and
> unmodified
> B
> Updates
> Let
>
>
|||replication with custom stored procedures.
Hilary Cotter
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Looking for a FAQ on Indexing Services/SQL FTS
http://www.indexserverfaq.com
"Raaj" <Raaj@.discussions.microsoft.com> wrote in message
news:501BF2AB-FF83-4EE4-9927-F80606684F85@.microsoft.com...[vbcol=seagreen]
> Thanks for the info .
> Can you please suggest me a mechanism for updatating the data back to the
> primary server from the Processing A DB .
> I am planning to use replication from Processing A back to the primary
> server ... any suggestion here
> Raj
> "Hilary Cotter" wrote:
basis[vbcol=seagreen]
whether[vbcol=seagreen]
back to[vbcol=seagreen]
and[vbcol=seagreen]
bit[vbcol=seagreen]
execute[vbcol=seagreen]
might[vbcol=seagreen]
this[vbcol=seagreen]
this[vbcol=seagreen]
Push[vbcol=seagreen]
field[vbcol=seagreen]
the[vbcol=seagreen]
Updates[vbcol=seagreen]
with[vbcol=seagreen]
will[vbcol=seagreen]
you do[vbcol=seagreen]
Primary[vbcol=seagreen]
Primary[vbcol=seagreen]
replication[vbcol=seagreen]
for a[vbcol=seagreen]
own[vbcol=seagreen]
..The[vbcol=seagreen]
DB.[vbcol=seagreen]
Processing[vbcol=seagreen]
this .[vbcol=seagreen]
info about sql server 2005 everywere
Hi ,
I must to realize a database application for an Automation system consisting of a Industrial PC with Operative System microsoft windows embedded.
I must to realize a database application for an Automation system consisting of a Industrial PC with Operative System microsoft windows embedded.
1° question: Is Microsoft sql server 2005 everywere compatible for Microsoft windows embedded?
(I ask this because in specific of its is not clear)
2° question: In the case that it's compatible, if I instal it in a industrial Pc can it to act by database server or necessity of a remote server?
Tanks
Yes, SQL Everywhere can run on Windows XP Embedded (I think that is what you are asking). It can be used as a local database for your embedded application without ever synchronizing with a server, and it can also use two data synchronization technologies called RDA and Merge Replication (included with SQL Everywhere) to achieve data synchronization.
Darren
Friday, March 23, 2012
Infinite Loop in cursor
Hi
I have an infinite loop in a trigger I and I cant reslove it.
In my system the user updates a stock table from the GUI and on the update I need to check values to see if I need to add records to a StockHistory table. For Example: If the user changes the grade of Product X from A to B then I need to add a new line in StockHistory for product X grade A that decrements the total number of products in the warehouse. Similary I need to increase the quantity of stock for Product X grade B.
I had the trigger working for single updates but now when stock is added to the database (from another db) it has status of 'New'. This isn't actually 'in stock' until the user sets the status to 'Goods In'. This process will then update the status for all records in the category. This caused my trigger to fail as the 'inserted' table now contains many records.
Now the problem I have is the trigger is in an infinite loop. It always shows the id of the first record it finds and the @.Quantity values increases as expected. I've taken all my procesing code out of the trigger and adding some debugging stuff but it still doesnt work:
CREATE TRIGGER [StockReturns_on_change] ON [dbo].[StockReturns]
FOR UPDATE
AS
DECLARE INDIVIDUAL Cursor Cursor for all the rows being updated
FOR
SELECT Id FROM inserted
OPEN INDIVIDUAL
FETCH NEXT FROM INDIVIDUAL INTO @.Id
select @.Quantity = 1
print @.@.FETCH_STATUS
print @.Id
print @.Quantity
WHILE @.@.FETCH_STATUS = 0
begin
select @.Quantity = @.Quantity + 1
print @.@.FETCH_STATUS
print @.Id
print @.Quantity
-- Get the next row from the inserted table
FETCH NEXT FROM INDIVIDUAL INTO @.Id
End -- While loop on the cursor
-- no close off the cursors
CLOSE INDIVIDUAL
DEALLOCATE INDIVIDUAL
Can you help me please?
Kind Regards
i think this is not an infinite query but a "long running" query. its going to finish
its just taking a lot of time
i suggest you get rid of the cursor replace it with a faster and better update code that process multiple records at the same time
use aggregate function(sum, count,min, max.. etc) in place of your counters (@.x=@.x+1)
cursors are very slow way of doing things
regards,
|||Thanks for the reply.
Nop its an infinite loop. The print statements show that id is always the same and the quanityt counter is being incremented showing that its travelling round the cursor. Or are you saying its looping around but still waiting for the first transaction to finish? I went out yesterday for 20 minutes and it was still showing the 1st record.
If I knew what code to write that would work then id do it. Unfortunatley this is the only way I can think of doing it.
Each record needs to be treated seperately as i have to inpect the values of 2 variables (both in inserted and deleted) to see if they have changed for each record. I cannot do a bulk insert.
|||here are your watch point
1. cursors are realy slow
2. maybe the triggers are in recurssion. meaning this trigger is fired by an update event of table1. in case the "update triggers" updates the same table (table1) again its going to call the same update trigger again and the cycle go an and on until 32 level deep per record.
if thats the case it will realy take a while to finish
solution:
you can write queries or correlated subqueries that joins your inserted and deleted table with the base tables to do the comparison.
such as
update basetable1 set fieldname = select count(xx) from
from inserted where inserted.id=basetable.id
in this way you do a one way trip to the server so even if it will be in recursion it is still fast
|||this trigger is on the stock table and it doesnt insert or update anything. Check the code i posted. It merely attempts to get the next value from the "inserted" table. I'm running that exact code and it does loop forever.
Heres dome debug ive collected whilst running the sql "Update stockreturns set itemstatus = 1 where id = 26301": (so its only updating 1 record)
0 fetch status
26301 id updating
1 loop counter
0
26301
2
0
26301
3
0
26301
4
0
26301
5
0
26301
6
0
26301
7
0
26301
8
0
26301
9
etc
Regards
|||i've modified your trigger and apply it to northind. employees
here's the code
use northwind
|||CREATE TRIGGER [StockReturns_on_change] ON [dbo].[employees]
FOR UPDATE
AS
declare @.id int
declare @.quantity int
DECLARE INDIVIDUAL Cursor Cursor for all the rows being updatedFOR
SELECT employeeId FROM insertedOPEN INDIVIDUAL
FETCH NEXT FROM INDIVIDUAL INTO @.Id
select @.Quantity = 1
print @.@.FETCH_STATUS
print @.Id
print @.QuantityWHILE @.@.FETCH_STATUS = 0
beginselect @.Quantity = @.Quantity + 1
print @.@.FETCH_STATUS
print @.Id
print @.Quantity-- Get the next row from the inserted table
FETCH NEXT FROM INDIVIDUAL INTO @.IdEnd -- While loop on the cursor
-- no close off the cursors
CLOSE INDIVIDUAL
DEALLOCATE INDIVIDUALgo
update employees set lastname='joey' where employeeid=1
and heres the result
0
1
1
0
1
2
now i've tried this
begin transaction
update employees set lastname='joey' where employeeid<6
and here's the result
0
1
1
0
1
2
0
2
3
0
3
4
0
4
5
0
5
6
(5 row(s) affected)
meaning this is not a infinite loop but a slow running query. how many records are you updating. by the way whats your requirements?
Hi Joey
Thanks for your efforts in trying to get me to understand!!
My requirements, ok here goes.
The user prints a stock manifest when stock comes into the warehouse which copies all the records to do with that manifest (store and date) from another database to my stock database. When these records are copied they are copied with a statusid of 0 (new stock). The manifest can have anywhere between 1 and 100 products on it.
The warehouse will then classify each product into grades A,B,C or D. The products by default are grade C in the database. After the products for this manifest have been classified a "goods in confirmation" report is produced which updates all the products on that manifest from statusid = 0 to statusid = 1 (goods in). Meaning that only now will they appear on stock reports and can be picked for despatched.
Now, we have a table called stockHistory which holds movements for every product (piece of equipment). Only when the products are cliassified as statusid = 1 do they offically enter the warehouse and so the historic table needs to be updated to include these products. Historic data is never changed or deleted. Only inserts are allowed. The historic table also holds the total number of each product in stock so when we are adding Product X Grade C to the warehouse we get the max(id) for Product X Grade C and increment the total quantity value by 1 as we are added a product to the warehouse of that type.
But, the stock can also go to Despatched which means we decrement a value. Despatched items have status of 5.
Also the grade of the stock can change which will mean we need to decrement from the old grade and increment from the new grade.
My trigger before i tried to get it working looked like:
SELECT @.newItemState = (SELECT itemStatus FROM Inserted)
SELECT @.oldItemState = (SELECT itemStatus FROM deleted)
select @.OldGrade = (select Grade from deleted) -- fetch the product id
select @.Grade = (select Grade from inserted) -- fetch the product id
DECLARE @.State tinyint
-- If its a product going to stock then insert
if (@.oldItemState = 0 and @.newItemState = 1)
begin
select @.State = 1
end
-- If the grade has changed we need to remove from old grade and add to new grade
else if (@.newItemState = 1 and @.Grade <> @.OldGrade)
begin
select @.State = 2
end
-- If the item has been dispatched remove from new grade
else if (@.newItemState = 5)
begin
select @.State = 3
end
so then i increment the current value on state 1 and 2 and decrement the value of the old product on state 2 and 3.
So if its state 1 or 3 then you use the values contained in "inserted" otherwise if state = 2 then i need to use the record of the old product grade "deleted" to decrement the quantity and use the new product grade to increment the quantity.
Damn that was hard work explaining, I hope that makes your understanding of my problem easier!!
At first I was under the impression that the trigger would fire for each SINGLE update but when I found out it didnt I thought looping round the inserted table was the thing to do.
So why does my loop go on forever and yours stops. Both bits of code are reading from the "inserted" table and simply printing the "id". We arent updating any other tables to cause a problem. Is there a setting in SQL 2000 which I have switched off?
Regards
|||You don't need a cursor loop to perform this logic. You can just do it via DML statements alone.
-- If its a product going to stock then insert
insert into ....
select ....
from inserted as i
join deleted as d
on d.key_col = i.key_col
where d.itemStatus = 0 and i.itemStatus = 1
-- If the grade has changed we need to remove from old grade and add to new grade
/* I am not sure if remove means update existing row or delete from table. */
Anyway, I hope you get the idea. Using cursor loop for this is probably overkill and has performance implications. It is much simpler to write series of DML statements by inspecting the rows of inserted/deleted tables as necessary. If you need more help then please post some sample schema, data and expected results for one particular case. You can then do the same for the rest.
|||OK cheers for that but Ive got one thing I have forgotten to say.
The stockHistory table contains 2 columns that come from a different table when the product is being despatched.
When a product is despatched the advicenote and processorid both need to be from the picklist table.
The stock table holds the fk to the picklist table called picklistid. From the picklist table I need the processorid and the despatchnote which get inserted into the processorid and advicenote columns respectively of the stockHistory table.
So I don't think I can simply do a bulk insert using data straight from the inserted table. Or can I?
Thanks
|||
UNBELIEVABLE!!
Joey, I just tried my code against the nortwind.employees table and it looped continuously. I tried your code and it worked.
I then have put your code against my stock table and run the upodate and it worked.
I've compared yours against mine and they are (as far as I can see) identical.
Im going to give it a go now and see what happens!!
Cheers
|||IVE GOT IT.
THE LINE
-- Get the next row from the inserted table
causes it to forever loop. Without this it works fine!
|||All sorted now and the trigger works fine.
Cheers for testing out my code Joey.
Inernet Explorer: "Illegal Operation"
Okay, I've tried everything else, so maybe someone out there on the great wi
de web can help!
Just after my system boots I start getting error messages:
IExplorer: This program has performed an illegal operation and will be shut
down.
Details: This program has caused a page fault in flt.dll.
When I try to close the dialog,it just keeps popping back up.
My computer usually freezes somewhere during all of this.
ctrl+alt+delete doesn't help, because then I get the message that IE isn't r
esponding.
My ScanDisk won't run because it says some program is running and it keeps r
estarting. The same thing happens iht the Defragmenter.
Okay someone tell me what to do!
DeloresThis newsgroup has nothing to do with Internet Explorer, it's a SQL Server
newsgroup. You might try asking in an Internet Explorer newsgroup such as
microsoft.public.windows.inetexplorer.ie6.browser , or
http://communities2.microsoft.com/c...&lang=en&cr=US.
Good luck,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"Delores" <msdrako223@.aol.com> wrote in message
news:FEF5236E-C8F1-46F3-9F5D-180029181CCA@.microsoft.com...
> Okay, I've tried everything else, so maybe someone out there on the great
wide web can help!
> Just after my system boots I start getting error messages:
> IExplorer: This program has performed an illegal operation and will be
shut down.
> Details: This program has caused a page fault in flt.dll.
> When I try to close the dialog,it just keeps popping back up.
> My computer usually freezes somewhere during all of this.
> ctrl+alt+delete doesn't help, because then I get the message that IE
isn't responding.
> My ScanDisk won't run because it says some program is running and it keeps
restarting. The same thing happens iht the Defragmenter.
> Okay someone tell me what to do!
> Delores
>|||This is, what, the 5th IE request in the last few days? How are these
people finding this group?
"Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
news:OqWByM8$DHA.1212@.TK2MSFTNGP12.phx.gbl...
> This newsgroup has nothing to do with Internet Explorer, it's a SQL Server
> newsgroup. You might try asking in an Internet Explorer newsgroup such as
> microsoft.public.windows.inetexplorer.ie6.browser , or
>
http://communities2.microsoft.com/c...s/default.aspx?
dg=microsoft.public.windows.inetexplorer.ie6.browser&cat=en-us-win-winclient
-internetexplorer&lang=en&cr=US.
> --
> Good luck,
> Stephen Dybing
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Delores" <msdrako223@.aol.com> wrote in message
> news:FEF5236E-C8F1-46F3-9F5D-180029181CCA@.microsoft.com...
great
> wide web can help!
> shut down.
> isn't responding.
keeps
> restarting. The same thing happens iht the Defragmenter.
>|||We occasionally go through periods like this, and have been for the past
couple of years. I suspect it happens every time some new website operator
discovers newsgroups and decides to make them available from their site.
Then when their users run into an IE problem, they start posting to
everything they see with "security" in the name. I've asked 3 or 4 times how
they got to this newsgroup and the only person who ever responded to me
didn't really say how they found it. I think it's just something we're going
to have to live with... :-(
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"Adam Machanic" <amachanic@.air-worldwide.nospamallowed.com> wrote in message
news:%23fJKc3TAEHA.220@.TK2MSFTNGP09.phx.gbl...
> This is, what, the 5th IE request in the last few days? How are these
> people finding this group?
>
> "Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
> news:OqWByM8$DHA.1212@.TK2MSFTNGP12.phx.gbl...
Server
as
>
http://communities2.microsoft.com/c...s/default.aspx?
>
dg=microsoft.public.windows.inetexplorer.ie6.browser&cat=en-us-win-winclient
> -internetexplorer&lang=en&cr=US.
> rights.
> great
> keeps
>
de web can help!
Just after my system boots I start getting error messages:
IExplorer: This program has performed an illegal operation and will be shut
down.
Details: This program has caused a page fault in flt.dll.
When I try to close the dialog,it just keeps popping back up.
My computer usually freezes somewhere during all of this.
ctrl+alt+delete doesn't help, because then I get the message that IE isn't r
esponding.
My ScanDisk won't run because it says some program is running and it keeps r
estarting. The same thing happens iht the Defragmenter.
Okay someone tell me what to do!
DeloresThis newsgroup has nothing to do with Internet Explorer, it's a SQL Server
newsgroup. You might try asking in an Internet Explorer newsgroup such as
microsoft.public.windows.inetexplorer.ie6.browser , or
http://communities2.microsoft.com/c...&lang=en&cr=US.
Good luck,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"Delores" <msdrako223@.aol.com> wrote in message
news:FEF5236E-C8F1-46F3-9F5D-180029181CCA@.microsoft.com...
> Okay, I've tried everything else, so maybe someone out there on the great
wide web can help!
> Just after my system boots I start getting error messages:
> IExplorer: This program has performed an illegal operation and will be
shut down.
> Details: This program has caused a page fault in flt.dll.
> When I try to close the dialog,it just keeps popping back up.
> My computer usually freezes somewhere during all of this.
> ctrl+alt+delete doesn't help, because then I get the message that IE
isn't responding.
> My ScanDisk won't run because it says some program is running and it keeps
restarting. The same thing happens iht the Defragmenter.
> Okay someone tell me what to do!
> Delores
>|||This is, what, the 5th IE request in the last few days? How are these
people finding this group?
"Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
news:OqWByM8$DHA.1212@.TK2MSFTNGP12.phx.gbl...
> This newsgroup has nothing to do with Internet Explorer, it's a SQL Server
> newsgroup. You might try asking in an Internet Explorer newsgroup such as
> microsoft.public.windows.inetexplorer.ie6.browser , or
>
http://communities2.microsoft.com/c...s/default.aspx?
dg=microsoft.public.windows.inetexplorer.ie6.browser&cat=en-us-win-winclient
-internetexplorer&lang=en&cr=US.
> --
> Good luck,
> Stephen Dybing
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Delores" <msdrako223@.aol.com> wrote in message
> news:FEF5236E-C8F1-46F3-9F5D-180029181CCA@.microsoft.com...
great
> wide web can help!
> shut down.
> isn't responding.
keeps
> restarting. The same thing happens iht the Defragmenter.
>|||We occasionally go through periods like this, and have been for the past
couple of years. I suspect it happens every time some new website operator
discovers newsgroups and decides to make them available from their site.
Then when their users run into an IE problem, they start posting to
everything they see with "security" in the name. I've asked 3 or 4 times how
they got to this newsgroup and the only person who ever responded to me
didn't really say how they found it. I think it's just something we're going
to have to live with... :-(
Sincerely,
Stephen Dybing
This posting is provided "AS IS" with no warranties, and confers no rights.
"Adam Machanic" <amachanic@.air-worldwide.nospamallowed.com> wrote in message
news:%23fJKc3TAEHA.220@.TK2MSFTNGP09.phx.gbl...
> This is, what, the 5th IE request in the last few days? How are these
> people finding this group?
>
> "Stephen Dybing [MSFT]" <stephd@.online.microsoft.com> wrote in message
> news:OqWByM8$DHA.1212@.TK2MSFTNGP12.phx.gbl...
Server
as
>
http://communities2.microsoft.com/c...s/default.aspx?
>
dg=microsoft.public.windows.inetexplorer.ie6.browser&cat=en-us-win-winclient
> -internetexplorer&lang=en&cr=US.
> rights.
> great
> keeps
>
Wednesday, March 7, 2012
Indexes on separate Filegroups
Two questions. Let's suppose I have two file groups, Primary and Datagroup.
The Primary group is mirrored and has my system tables and transaction log
(Drive letter "D"). My tables and indexes are in the Datagroup on a separate
RAID 5 disk configuration (Drive letter "E"). Let us suppose I have available
a third RAID 5 disk configuration (Drive letter "F").
1. I just wanted to verify a thought: If all my tables have clustered indexes,
and since clustered indexes reside on the data pages themselves, then it
would NOT make sense to put my clustered indexes on a separate file or disk
from my data file. True or False? My guess is that the answer is true. Please
verify.
2. In the case of non-clustered indexes (where all the corresponding tables
have clustered indexes), there could possibly be a performance gain by
placing the non-clustered indexes on a separate file (say, Drive letter "F")
from my data. True or False? My guess is that the answer is true. Please
verify.
Message posted via http://www.droptable.com
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:5e60b49711dd2@.uwe...
> Two questions. Let's suppose I have two file groups, Primary and
> Datagroup.
> The Primary group is mirrored and has my system tables and transaction log
> (Drive letter "D"). My tables and indexes are in the Datagroup on a
> separate
> RAID 5 disk configuration (Drive letter "E"). Let us suppose I have
> available
> a third RAID 5 disk configuration (Drive letter "F").
> 1. I just wanted to verify a thought: If all my tables have clustered
> indexes,
> and since clustered indexes reside on the data pages themselves, then it
> would NOT make sense to put my clustered indexes on a separate file or
> disk
> from my data file. True or False? My guess is that the answer is true.
> Please
> verify.
>
True. That would just move the tables to the other filegroup.
> 2. In the case of non-clustered indexes (where all the corresponding
> tables
> have clustered indexes), there could possibly be a performance gain by
> placing the non-clustered indexes on a separate file (say, Drive letter
> "F")
> from my data. True or False? My guess is that the answer is true. Please
> verify.
False. Seperating tables and indexes rarely helps, and is essentially an
obsolete micro-optimization of the physical database design. The large
memory size of modern servers makes physical IO on your non-clustered
indexes rare and unpredictable enough that you shouldn't dedicate a physical
IO channel to your indexes. A better idea would be to spread all your
objects across both disks by adding additional files to your data filegroup,
or monitor your physical IO and move objects to the other disk to roughly
balance the traffic.
David
The Primary group is mirrored and has my system tables and transaction log
(Drive letter "D"). My tables and indexes are in the Datagroup on a separate
RAID 5 disk configuration (Drive letter "E"). Let us suppose I have available
a third RAID 5 disk configuration (Drive letter "F").
1. I just wanted to verify a thought: If all my tables have clustered indexes,
and since clustered indexes reside on the data pages themselves, then it
would NOT make sense to put my clustered indexes on a separate file or disk
from my data file. True or False? My guess is that the answer is true. Please
verify.
2. In the case of non-clustered indexes (where all the corresponding tables
have clustered indexes), there could possibly be a performance gain by
placing the non-clustered indexes on a separate file (say, Drive letter "F")
from my data. True or False? My guess is that the answer is true. Please
verify.
Message posted via http://www.droptable.com
"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:5e60b49711dd2@.uwe...
> Two questions. Let's suppose I have two file groups, Primary and
> Datagroup.
> The Primary group is mirrored and has my system tables and transaction log
> (Drive letter "D"). My tables and indexes are in the Datagroup on a
> separate
> RAID 5 disk configuration (Drive letter "E"). Let us suppose I have
> available
> a third RAID 5 disk configuration (Drive letter "F").
> 1. I just wanted to verify a thought: If all my tables have clustered
> indexes,
> and since clustered indexes reside on the data pages themselves, then it
> would NOT make sense to put my clustered indexes on a separate file or
> disk
> from my data file. True or False? My guess is that the answer is true.
> Please
> verify.
>
True. That would just move the tables to the other filegroup.
> 2. In the case of non-clustered indexes (where all the corresponding
> tables
> have clustered indexes), there could possibly be a performance gain by
> placing the non-clustered indexes on a separate file (say, Drive letter
> "F")
> from my data. True or False? My guess is that the answer is true. Please
> verify.
False. Seperating tables and indexes rarely helps, and is essentially an
obsolete micro-optimization of the physical database design. The large
memory size of modern servers makes physical IO on your non-clustered
indexes rare and unpredictable enough that you shouldn't dedicate a physical
IO channel to your indexes. A better idea would be to spread all your
objects across both disks by adding additional files to your data filegroup,
or monitor your physical IO and move objects to the other disk to roughly
balance the traffic.
David
Indexes on separate Filegroups
Two questions. Let's suppose I have two file groups, Primary and Datagroup.
The Primary group is mirrored and has my system tables and transaction log
(Drive letter "D"). My tables and indexes are in the Datagroup on a separate
RAID 5 disk configuration (Drive letter "E"). Let us suppose I have availabl
e
a third RAID 5 disk configuration (Drive letter "F").
1. I just wanted to verify a thought: If all my tables have clustered indexe
s,
and since clustered indexes reside on the data pages themselves, then it
would NOT make sense to put my clustered indexes on a separate file or disk
from my data file. True or False? My guess is that the answer is true. Pleas
e
verify.
2. In the case of non-clustered indexes (where all the corresponding tables
have clustered indexes), there could possibly be a performance gain by
placing the non-clustered indexes on a separate file (say, Drive letter "F")
from my data. True or False? My guess is that the answer is true. Please
verify.
Message posted via http://www.droptable.com"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:5e60b49711dd2@.uwe...
> Two questions. Let's suppose I have two file groups, Primary and
> Datagroup.
> The Primary group is mirrored and has my system tables and transaction log
> (Drive letter "D"). My tables and indexes are in the Datagroup on a
> separate
> RAID 5 disk configuration (Drive letter "E"). Let us suppose I have
> available
> a third RAID 5 disk configuration (Drive letter "F").
> 1. I just wanted to verify a thought: If all my tables have clustered
> indexes,
> and since clustered indexes reside on the data pages themselves, then it
> would NOT make sense to put my clustered indexes on a separate file or
> disk
> from my data file. True or False? My guess is that the answer is true.
> Please
> verify.
>
True. That would just move the tables to the other filegroup.
> 2. In the case of non-clustered indexes (where all the corresponding
> tables
> have clustered indexes), there could possibly be a performance gain by
> placing the non-clustered indexes on a separate file (say, Drive letter
> "F")
> from my data. True or False? My guess is that the answer is true. Please
> verify.
False. Seperating tables and indexes rarely helps, and is essentially an
obsolete micro-optimization of the physical database design. The large
memory size of modern servers makes physical IO on your non-clustered
indexes rare and unpredictable enough that you shouldn't dedicate a physical
IO channel to your indexes. A better idea would be to spread all your
objects across both disks by adding additional files to your data filegroup,
or monitor your physical IO and move objects to the other disk to roughly
balance the traffic.
David
The Primary group is mirrored and has my system tables and transaction log
(Drive letter "D"). My tables and indexes are in the Datagroup on a separate
RAID 5 disk configuration (Drive letter "E"). Let us suppose I have availabl
e
a third RAID 5 disk configuration (Drive letter "F").
1. I just wanted to verify a thought: If all my tables have clustered indexe
s,
and since clustered indexes reside on the data pages themselves, then it
would NOT make sense to put my clustered indexes on a separate file or disk
from my data file. True or False? My guess is that the answer is true. Pleas
e
verify.
2. In the case of non-clustered indexes (where all the corresponding tables
have clustered indexes), there could possibly be a performance gain by
placing the non-clustered indexes on a separate file (say, Drive letter "F")
from my data. True or False? My guess is that the answer is true. Please
verify.
Message posted via http://www.droptable.com"cbrichards via droptable.com" <u3288@.uwe> wrote in message
news:5e60b49711dd2@.uwe...
> Two questions. Let's suppose I have two file groups, Primary and
> Datagroup.
> The Primary group is mirrored and has my system tables and transaction log
> (Drive letter "D"). My tables and indexes are in the Datagroup on a
> separate
> RAID 5 disk configuration (Drive letter "E"). Let us suppose I have
> available
> a third RAID 5 disk configuration (Drive letter "F").
> 1. I just wanted to verify a thought: If all my tables have clustered
> indexes,
> and since clustered indexes reside on the data pages themselves, then it
> would NOT make sense to put my clustered indexes on a separate file or
> disk
> from my data file. True or False? My guess is that the answer is true.
> Please
> verify.
>
True. That would just move the tables to the other filegroup.
> 2. In the case of non-clustered indexes (where all the corresponding
> tables
> have clustered indexes), there could possibly be a performance gain by
> placing the non-clustered indexes on a separate file (say, Drive letter
> "F")
> from my data. True or False? My guess is that the answer is true. Please
> verify.
False. Seperating tables and indexes rarely helps, and is essentially an
obsolete micro-optimization of the physical database design. The large
memory size of modern servers makes physical IO on your non-clustered
indexes rare and unpredictable enough that you shouldn't dedicate a physical
IO channel to your indexes. A better idea would be to spread all your
objects across both disks by adding additional files to your data filegroup,
or monitor your physical IO and move objects to the other disk to roughly
balance the traffic.
David
Indexes on separate Filegroups
Two questions. Let's suppose I have two file groups, Primary and Datagroup.
The Primary group is mirrored and has my system tables and transaction log
(Drive letter "D"). My tables and indexes are in the Datagroup on a separate
RAID 5 disk configuration (Drive letter "E"). Let us suppose I have available
a third RAID 5 disk configuration (Drive letter "F").
1. I just wanted to verify a thought: If all my tables have clustered indexes,
and since clustered indexes reside on the data pages themselves, then it
would NOT make sense to put my clustered indexes on a separate file or disk
from my data file. True or False? My guess is that the answer is true. Please
verify.
2. In the case of non-clustered indexes (where all the corresponding tables
have clustered indexes), there could possibly be a performance gain by
placing the non-clustered indexes on a separate file (say, Drive letter "F")
from my data. True or False? My guess is that the answer is true. Please
verify.
--
Message posted via http://www.sqlmonster.com"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:5e60b49711dd2@.uwe...
> Two questions. Let's suppose I have two file groups, Primary and
> Datagroup.
> The Primary group is mirrored and has my system tables and transaction log
> (Drive letter "D"). My tables and indexes are in the Datagroup on a
> separate
> RAID 5 disk configuration (Drive letter "E"). Let us suppose I have
> available
> a third RAID 5 disk configuration (Drive letter "F").
> 1. I just wanted to verify a thought: If all my tables have clustered
> indexes,
> and since clustered indexes reside on the data pages themselves, then it
> would NOT make sense to put my clustered indexes on a separate file or
> disk
> from my data file. True or False? My guess is that the answer is true.
> Please
> verify.
>
True. That would just move the tables to the other filegroup.
> 2. In the case of non-clustered indexes (where all the corresponding
> tables
> have clustered indexes), there could possibly be a performance gain by
> placing the non-clustered indexes on a separate file (say, Drive letter
> "F")
> from my data. True or False? My guess is that the answer is true. Please
> verify.
False. Seperating tables and indexes rarely helps, and is essentially an
obsolete micro-optimization of the physical database design. The large
memory size of modern servers makes physical IO on your non-clustered
indexes rare and unpredictable enough that you shouldn't dedicate a physical
IO channel to your indexes. A better idea would be to spread all your
objects across both disks by adding additional files to your data filegroup,
or monitor your physical IO and move objects to the other disk to roughly
balance the traffic.
David
The Primary group is mirrored and has my system tables and transaction log
(Drive letter "D"). My tables and indexes are in the Datagroup on a separate
RAID 5 disk configuration (Drive letter "E"). Let us suppose I have available
a third RAID 5 disk configuration (Drive letter "F").
1. I just wanted to verify a thought: If all my tables have clustered indexes,
and since clustered indexes reside on the data pages themselves, then it
would NOT make sense to put my clustered indexes on a separate file or disk
from my data file. True or False? My guess is that the answer is true. Please
verify.
2. In the case of non-clustered indexes (where all the corresponding tables
have clustered indexes), there could possibly be a performance gain by
placing the non-clustered indexes on a separate file (say, Drive letter "F")
from my data. True or False? My guess is that the answer is true. Please
verify.
--
Message posted via http://www.sqlmonster.com"cbrichards via SQLMonster.com" <u3288@.uwe> wrote in message
news:5e60b49711dd2@.uwe...
> Two questions. Let's suppose I have two file groups, Primary and
> Datagroup.
> The Primary group is mirrored and has my system tables and transaction log
> (Drive letter "D"). My tables and indexes are in the Datagroup on a
> separate
> RAID 5 disk configuration (Drive letter "E"). Let us suppose I have
> available
> a third RAID 5 disk configuration (Drive letter "F").
> 1. I just wanted to verify a thought: If all my tables have clustered
> indexes,
> and since clustered indexes reside on the data pages themselves, then it
> would NOT make sense to put my clustered indexes on a separate file or
> disk
> from my data file. True or False? My guess is that the answer is true.
> Please
> verify.
>
True. That would just move the tables to the other filegroup.
> 2. In the case of non-clustered indexes (where all the corresponding
> tables
> have clustered indexes), there could possibly be a performance gain by
> placing the non-clustered indexes on a separate file (say, Drive letter
> "F")
> from my data. True or False? My guess is that the answer is true. Please
> verify.
False. Seperating tables and indexes rarely helps, and is essentially an
obsolete micro-optimization of the physical database design. The large
memory size of modern servers makes physical IO on your non-clustered
indexes rare and unpredictable enough that you shouldn't dedicate a physical
IO channel to your indexes. A better idea would be to spread all your
objects across both disks by adding additional files to your data filegroup,
or monitor your physical IO and move objects to the other disk to roughly
balance the traffic.
David
Indexes getting fragmented very quickly
We have been running SQL Server 2000 on a production machine for years.
Within the last 6 months, we have noticed a performance problem. The
system will suddenly slow to a crawl. We run DBCC Reindex for all of
the tables in the our database, and things go back to normal - running
very quickly. We are currently having to do this multiple times a day.
We have verified the indexes are getting fragmented by using the DBCC
showcontig. What will cause the indexes to get fragmented so quickly?
How do we prevent this from happening?
Any help would greatly be appreciated.
Thank you!
Jayme> What will cause the indexes to get fragmented so quickly?
Some possibilities:
Lots of inserts over a key that is no monotonically increasing.
Lost of updates (where value in index key changes).
Shrinking of database files.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Jayme" <jayloub@.comcast.net> wrote in message
news:1150568837.067145.140050@.c74g2000cwc.googlegroups.com...
> We have been running SQL Server 2000 on a production machine for years.
> Within the last 6 months, we have noticed a performance problem. The
> system will suddenly slow to a crawl. We run DBCC Reindex for all of
> the tables in the our database, and things go back to normal - running
> very quickly. We are currently having to do this multiple times a day.
> We have verified the indexes are getting fragmented by using the DBCC
> showcontig. What will cause the indexes to get fragmented so quickly?
> How do we prevent this from happening?
> Any help would greatly be appreciated.
> Thank you!
> Jayme
>|||Jayme wrote:
> We have been running SQL Server 2000 on a production machine for years.
> Within the last 6 months, we have noticed a performance problem. The
> system will suddenly slow to a crawl. We run DBCC Reindex for all of
> the tables in the our database, and things go back to normal - running
> very quickly. We are currently having to do this multiple times a day.
> We have verified the indexes are getting fragmented by using the DBCC
> showcontig. What will cause the indexes to get fragmented so quickly?
> How do we prevent this from happening?
> Any help would greatly be appreciated.
> Thank you!
> Jayme
>
Are you sure you're seeing index fragmentation, and not disk
fragmentation? Post the output of your DBCC command..|||Tracy McKibben wrote:
> Jayme wrote:
> > We have been running SQL Server 2000 on a production machine for years.
> > Within the last 6 months, we have noticed a performance problem. The
> > system will suddenly slow to a crawl. We run DBCC Reindex for all of
> > the tables in the our database, and things go back to normal - running
> > very quickly. We are currently having to do this multiple times a day.
> > We have verified the indexes are getting fragmented by using the DBCC
> > showcontig. What will cause the indexes to get fragmented so quickly?
> > How do we prevent this from happening?
> >
> > Any help would greatly be appreciated.
> > Thank you!
> > Jayme
> >
> Are you sure you're seeing index fragmentation, and not disk
> fragmentation? Post the output of your DBCC command..
Check out for disk fragmentation also.
If Index fragmentation , then BOL has very good sample, in DBCC
Showconting topic.
It will check index fragmentation and defrag index which are fragmented
below threshold value. Run it regularly.
Regards
Amish Shah|||This is the dbcc output before the reindex is done:
DBCC SHOWCONTIG scanning 'QCSKUTable' table...
Table: 'QCSKUTable' (32771224); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 533
- Extents Scanned.......................: 68
- Extent Switches.......................: 67
- Avg. Pages per Extent..................: 7.8
- Scan Density [Best Count:Actual Count]......: 98.53% [67:68]
- Logical Scan Fragmentation ..............: 9.01%
- Extent Scan Fragmentation ...............: 72.06%
- Avg. Bytes Free per Page................: 789.2
- Avg. Page Density (full)................: 90.25%
DBCC SHOWCONTIG scanning 'Map' table...
Table: 'Map' (101575400); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 6089.0
- Avg. Page Density (full)................: 24.77%
DBCC SHOWCONTIG scanning 'Zone' table...
Table: 'Zone' (133575514); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 70
- Extents Scanned.......................: 9
- Extent Switches.......................: 8
- Avg. Pages per Extent..................: 7.8
- Scan Density [Best Count:Actual Count]......: 100.00% [9:9]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 11.11%
- Avg. Bytes Free per Page................: 837.4
- Avg. Page Density (full)................: 89.65%
DBCC SHOWCONTIG scanning 'QCConfiguration' table...
Table: 'QCConfiguration' (192771794); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 6976.0
- Avg. Page Density (full)................: 13.81%
DBCC SHOWCONTIG scanning 'TestQCSKUTable' table...
Table: 'TestQCSKUTable' (230395990); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 535
- Extents Scanned.......................: 68
- Extent Switches.......................: 67
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 98.53% [67:68]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 67.65%
- Avg. Bytes Free per Page................: 786.5
- Avg. Page Density (full)................: 90.28%
DBCC SHOWCONTIG scanning 'Bay' table...
Table: 'Bay' (325576198); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 5
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 5.0
- Scan Density [Best Count:Actual Count]......: 100.00% [1:1]
- Logical Scan Fragmentation ..............: 20.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 2084.0
- Avg. Page Density (full)................: 74.25%
DBCC SHOWCONTIG scanning 'ZoneMap' table...
Table: 'ZoneMap' (357576312); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 309
- Extents Scanned.......................: 39
- Extent Switches.......................: 38
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 100.00% [39:39]
- Logical Scan Fragmentation ..............: 0.32%
- Extent Scan Fragmentation ...............: 69.23%
- Avg. Bytes Free per Page................: 799.9
- Avg. Page Density (full)................: 90.12%
DBCC SHOWCONTIG scanning 'Device' table...
Table: 'Device' (421576540); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 293
- Extents Scanned.......................: 37
- Extent Switches.......................: 36
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 100.00% [37:37]
- Logical Scan Fragmentation ..............: 0.34%
- Extent Scan Fragmentation ...............: 81.08%
- Avg. Bytes Free per Page................: 779.5
- Avg. Page Density (full)................: 90.37%
DBCC SHOWCONTIG scanning 'Location' table...
Table: 'Location' (501576825); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 285
- Extents Scanned.......................: 36
- Extent Switches.......................: 35
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 100.00% [36:36]
- Logical Scan Fragmentation ..............: 0.35%
- Extent Scan Fragmentation ...............: 5.56%
- Avg. Bytes Free per Page................: 786.2
- Avg. Page Density (full)................: 90.29%
DBCC SHOWCONTIG scanning 'Carrier' table...
Table: 'Carrier' (580913141); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 232
- Extents Scanned.......................: 34
- Extent Switches.......................: 33
- Avg. Pages per Extent..................: 6.8
- Scan Density [Best Count:Actual Count]......: 85.29% [29:34]
- Extent Scan Fragmentation ...............: 94.12%
- Avg. Bytes Free per Page................: 1359.3
- Avg. Page Density (full)................: 83.21%
DBCC SHOWCONTIG scanning 'NetController' table...
Table: 'NetController' (581577110); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 3
- Extent Switches.......................: 2
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 33.33% [1:3]
- Logical Scan Fragmentation ..............: 33.33%
- Extent Scan Fragmentation ...............: 33.33%
- Avg. Bytes Free per Page................: 1356.0
- Avg. Page Density (full)................: 83.25%
DBCC SHOWCONTIG scanning 'QCContentDetail' table...
Table: 'QCContentDetail' (596249229); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 8
- Extents Scanned.......................: 6
- Extent Switches.......................: 6
- Avg. Pages per Extent..................: 1.3
- Scan Density [Best Count:Actual Count]......: 14.29% [1:7]
- Logical Scan Fragmentation ..............: 50.00%
- Extent Scan Fragmentation ...............: 66.67%
- Avg. Bytes Free per Page................: 3306.5
- Avg. Page Density (full)................: 59.15%
DBCC SHOWCONTIG scanning 'OrderToCarrier' table...
Table: 'OrderToCarrier' (628913312); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 139
- Extents Scanned.......................: 31
- Extent Switches.......................: 30
- Avg. Pages per Extent..................: 4.5
- Scan Density [Best Count:Actual Count]......: 58.06% [18:31]
- Extent Scan Fragmentation ...............: 96.77%
- Avg. Bytes Free per Page................: 1491.1
- Avg. Page Density (full)................: 81.58%
DBCC SHOWCONTIG scanning 'WaveGroup' table...
Table: 'WaveGroup' (645577338); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7988.0
- Avg. Page Density (full)................: 1.31%
DBCC SHOWCONTIG scanning 'WorkLoadCriteriaDetail' table...
Table: 'WorkLoadCriteriaDetail' (654625375); index ID: 1, database ID:
6
TABLE level scan performed.
- Pages Scanned........................: 9
- Extents Scanned.......................: 2
- Extent Switches.......................: 1
- Avg. Pages per Extent..................: 4.5
- Scan Density [Best Count:Actual Count]......: 100.00% [2:2]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 970.7
- Avg. Page Density (full)................: 88.01%
DBCC SHOWCONTIG scanning 'Products' table...
Table: 'Products' (660913426); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 8056.0
- Avg. Page Density (full)................: 0.47%
DBCC SHOWCONTIG scanning 'CloseToteData' table...
Table: 'CloseToteData' (691025743); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 17307
- Extents Scanned.......................: 2167
- Extent Switches.......................: 2166
- Avg. Pages per Extent..................: 8.0
- Scan Density [Best Count:Actual Count]......: 99.86% [2164:2167]
- Extent Scan Fragmentation ...............: 18.00%
- Avg. Bytes Free per Page................: 356.5
- Avg. Page Density (full)................: 95.60%
DBCC SHOWCONTIG scanning 'OrderState' table...
Table: 'OrderState' (692913540); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7561.0
- Avg. Page Density (full)................: 6.59%
DBCC SHOWCONTIG scanning 'Wave' table...
Table: 'Wave' (709577566); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 4796.0
- Avg. Page Density (full)................: 40.75%
DBCC SHOWCONTIG scanning 'LNG' table...
Table: 'LNG' (715149593); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 25
- Extents Scanned.......................: 4
- Extent Switches.......................: 3
- Avg. Pages per Extent..................: 6.3
- Scan Density [Best Count:Actual Count]......: 100.00% [4:4]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 916.6
- Avg. Page Density (full)................: 88.68%
DBCC SHOWCONTIG scanning 'WaveState' table...
Table: 'WaveState' (724913654); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7659.0
- Avg. Page Density (full)................: 5.37%
DBCC SHOWCONTIG scanning 'PCS_Object' table...
Table: 'PCS_Object' (747149707); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 905.0
- Avg. Page Density (full)................: 88.82%
DBCC SHOWCONTIG scanning 'WaveByProduct' table...
Table: 'WaveByProduct' (756913768); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 8
- Extents Scanned.......................: 5
- Extent Switches.......................: 4
- Avg. Pages per Extent..................: 1.6
- Scan Density [Best Count:Actual Count]......: 20.00% [1:5]
- Extent Scan Fragmentation ...............: 80.00%
- Avg. Bytes Free per Page................: 7734.6
- Avg. Page Density (full)................: 4.44%
DBCC SHOWCONTIG scanning 'LineItem' table...
Table: 'LineItem' (762902235); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 5894
- Extents Scanned.......................: 745
- Extent Switches.......................: 744
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 98.93% [737:745]
- Extent Scan Fragmentation ...............: 89.13%
- Avg. Bytes Free per Page................: 1303.0
- Avg. Page Density (full)................: 83.90%
DBCC SHOWCONTIG scanning 'PCS_User' table...
Table: 'PCS_User' (779149821); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 3.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................: 1251.7
- Avg. Page Density (full)................: 84.54%
DBCC SHOWCONTIG scanning 'Wave' table...
Table: 'Wave' (788913882); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 8
- Extents Scanned.......................: 7
- Extent Switches.......................: 6
- Avg. Pages per Extent..................: 1.1
- Scan Density [Best Count:Actual Count]......: 14.29% [1:7]
- Extent Scan Fragmentation ...............: 57.14%
- Avg. Bytes Free per Page................: 7723.8
- Avg. Page Density (full)................: 4.57%
DBCC SHOWCONTIG scanning 'PDSynchronize' table...
Table: 'PDSynchronize' (794902349); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 3.0
- Scan Density [Best Count:Actual Count]......: 100.00% [1:1]
- Logical Scan Fragmentation ..............: 66.67%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 3770.7
- Avg. Page Density (full)................: 53.41%
DBCC SHOWCONTIG scanning 'PCS_PermissionGroup' table...
Table: 'PCS_PermissionGroup' (811149935); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7319.0
- Avg. Page Density (full)................: 9.57%
DBCC SHOWCONTIG scanning 'Order' table...
Table: 'Order' (836914053); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 364
- Extents Scanned.......................: 55
- Extent Switches.......................: 54
- Avg. Pages per Extent..................: 6.6
- Scan Density [Best Count:Actual Count]......: 83.64% [46:55]
- Extent Scan Fragmentation ...............: 98.18%
- Avg. Bytes Free per Page................: 1263.0
- Avg. Page Density (full)................: 84.40%
DBCC SHOWCONTIG scanning 'Task' table...
Table: 'Task' (837578022); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 296
- Extents Scanned.......................: 42
- Extent Switches.......................: 43
- Avg. Pages per Extent..................: 7.0
- Scan Density [Best Count:Actual Count]......: 84.09% [37:44]
- Logical Scan Fragmentation ..............: 0.68%
- Extent Scan Fragmentation ...............: 64.29%
- Avg. Bytes Free per Page................: 843.2
- Avg. Page Density (full)................: 89.58%
DBCC SHOWCONTIG scanning 'PCS_Component' table...
Table: 'PCS_Component' (843150049); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 5189.0
- Avg. Page Density (full)................: 35.89%
DBCC SHOWCONTIG scanning 'QCEventLog' table...
Table: 'QCEventLog' (843918128); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3603
- Extents Scanned.......................: 465
- Extent Switches.......................: 464
- Avg. Pages per Extent..................: 7.7
- Scan Density [Best Count:Actual Count]......: 96.99% [451:465]
- Extent Scan Fragmentation ...............: 36.99%
- Avg. Bytes Free per Page................: 575.1
- Avg. Page Density (full)................: 92.89%
DBCC SHOWCONTIG scanning 'OrderLine' table...
Table: 'OrderLine' (884914224); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 6298
- Extents Scanned.......................: 798
- Extent Switches.......................: 797
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 98.75% [788:798]
- Extent Scan Fragmentation ...............: 98.37%
- Avg. Bytes Free per Page................: 255.3
- Avg. Page Density (full)................: 96.85%
DBCC SHOWCONTIG scanning 'PCS_PermissionGroupHasPL1' table...
Table: 'PCS_PermissionGroupHasPL1' (891150220); index ID: 1, database
ID: 6
TABLE level scan performed.
- 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................: 2068.0
- Avg. Page Density (full)................: 74.45%
DBCC SHOWCONTIG scanning 'QCErrors' table...
Table: 'QCErrors' (923918413); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 10
- Extents Scanned.......................: 2
- Extent Switches.......................: 1
- Avg. Pages per Extent..................: 5.0
- Scan Density [Best Count:Actual Count]......: 100.00% [2:2]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 848.3
- Avg. Page Density (full)................: 89.52%
DBCC SHOWCONTIG scanning 'StateTransitionTimes' table...
Table: 'StateTransitionTimes' (932914395); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 590
- Extents Scanned.......................: 100
- Extent Switches.......................: 99
- Avg. Pages per Extent..................: 5.9
- Scan Density [Best Count:Actual Count]......: 74.00% [74:100]
- Extent Scan Fragmentation ...............: 91.00%
- Avg. Bytes Free per Page................: 599.8
- Avg. Page Density (full)................: 92.59%
DBCC SHOWCONTIG scanning 'PCS_UserInPermissionGroup' table...
Table: 'PCS_UserInPermissionGroup' (955150448); index ID: 1, database
ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 3
- Extent Switches.......................: 2
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 33.33% [1:3]
- Logical Scan Fragmentation ..............: 33.33%
- Extent Scan Fragmentation ...............: 66.67%
- Avg. Bytes Free per Page................: 869.0
- Avg. Page Density (full)................: 89.26%
DBCC SHOWCONTIG scanning 'PickMission' table...
Table: 'PickMission' (964914509); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3950
- Extents Scanned.......................: 499
- Extent Switches.......................: 498
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 99.00% [494:499]
- Extent Scan Fragmentation ...............: 99.20%
- Avg. Bytes Free per Page................: 279.3
- Avg. Page Density (full)................: 96.55%
DBCC SHOWCONTIG scanning 'Mission' table...
Table: 'Mission' (965578478); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 346
- Extents Scanned.......................: 52
- Extent Switches.......................: 53
- Avg. Pages per Extent..................: 6.7
- Scan Density [Best Count:Actual Count]......: 81.48% [44:54]
- Logical Scan Fragmentation ..............: 1.16%
- Extent Scan Fragmentation ...............: 82.69%
- Avg. Bytes Free per Page................: 876.8
- Avg. Page Density (full)................: 89.17%
DBCC SHOWCONTIG scanning 'QCMasterList' table...
Table: 'QCMasterList' (1003918698); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 984
- Extents Scanned.......................: 128
- Extent Switches.......................: 133
- Avg. Pages per Extent..................: 7.7
- Scan Density [Best Count:Actual Count]......: 91.79% [123:134]
- Logical Scan Fragmentation ..............: 1.12%
- Extent Scan Fragmentation ...............: 64.06%
- Avg. Bytes Free per Page................: 753.2
- Avg. Page Density (full)................: 90.69%
DBCC SHOWCONTIG scanning 'PCS_Client' table...
Table: 'PCS_Client' (1019150676); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7427.0
- Avg. Page Density (full)................: 8.24%
DBCC SHOWCONTIG scanning 'PCS_ClientRestriction' table...
Table: 'PCS_ClientRestriction' (1051150790); index ID: 1, database ID:
6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7780.0
- Avg. Page Density (full)................: 3.88%
DBCC SHOWCONTIG scanning 'PickMissionComplete' table...
Table: 'PickMissionComplete' (1060914851); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 1661
- Extents Scanned.......................: 461
- Extent Switches.......................: 460
- Avg. Pages per Extent..................: 3.6
- Scan Density [Best Count:Actual Count]......: 45.12% [208:461]
- Extent Scan Fragmentation ...............: 66.81%
- Avg. Bytes Free per Page................: 2926.2
- Avg. Page Density (full)................: 63.85%
DBCC SHOWCONTIG scanning 'UISCFG_Band' table...
Table: 'UISCFG_Band' (1083150904); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 6640.0
- Avg. Page Density (full)................: 17.96%
DBCC SHOWCONTIG scanning 'CurrentActivity' table...
Table: 'CurrentActivity' (1093578934); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 743.0
- Avg. Page Density (full)................: 90.82%
DBCC SHOWCONTIG scanning 'UISCFG_ComponentEntry' table...
Table: 'UISCFG_ComponentEntry' (1115151018); index ID: 1, database ID:
6
TABLE level scan performed.
- Pages Scanned........................: 2
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 2.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................: 816.0
- Avg. Page Density (full)................: 89.92%
DBCC SHOWCONTIG scanning 'Configuration' table...
Table: 'Configuration' (1156915193); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7690.0
- Avg. Page Density (full)................: 4.99%
DBCC SHOWCONTIG scanning 'UISCFG_CE_on_Band' table...
Table: 'UISCFG_CE_on_Band' (1163151189); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 4881.0
- Avg. Page Density (full)................: 39.70%
DBCC SHOWCONTIG scanning 'UISCFG_Treeview' table...
Table: 'UISCFG_Treeview' (1227151417); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 3117.0
- Avg. Page Density (full)................: 61.49%
DBCC SHOWCONTIG scanning 'UISCFG_Events' table...
Table: 'UISCFG_Events' (1307151702); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 8051.0
- Avg. Page Density (full)................: 0.53%
DBCC SHOWCONTIG scanning 'IAS_AutoInteraction' table...
Table: 'IAS_AutoInteraction' (1323151759); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 2797.0
- Avg. Page Density (full)................: 65.44%
DBCC SHOWCONTIG scanning 'WorkLoadRollup' table...
Table: 'WorkLoadRollup' (1332199796); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 2370
- Extents Scanned.......................: 298
- Extent Switches.......................: 297
- Avg. Pages per Extent..................: 8.0
- Scan Density [Best Count:Actual Count]......: 99.66% [297:298]
- Logical Scan Fragmentation ..............: 9.66%
- Extent Scan Fragmentation ...............: 61.07%
- Avg. Bytes Free per Page................: 696.5
- Avg. Page Density (full)................: 91.39%
DBCC SHOWCONTIG scanning 'MissionDetail' table...
Table: 'MissionDetail' (1349579846); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 1494
- Extents Scanned.......................: 189
- Extent Switches.......................: 855
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 21.85% [187:856]
- Logical Scan Fragmentation ..............: 27.58%
- Extent Scan Fragmentation ...............: 89.42%
- Avg. Bytes Free per Page................: 4327.5
- Avg. Page Density (full)................: 46.54%
DBCC SHOWCONTIG scanning 'UISCFG_SystemParameters' table...
Table: 'UISCFG_SystemParameters' (1355151873); index ID: 1, database
ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7984.0
- Avg. Page Density (full)................: 1.36%
DBCC SHOWCONTIG scanning 'UISCFG_ProductInfo' table...
Table: 'UISCFG_ProductInfo' (1387151987); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 8048.0
- Avg. Page Density (full)................: 0.57%
DBCC SHOWCONTIG scanning 'UISCFG_UserPreferences' table...
Table: 'UISCFG_UserPreferences' (1419152101); index ID: 1, database ID:
6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 3
- Extent Switches.......................: 2
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 33.33% [1:3]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 66.67%
- Avg. Bytes Free per Page................: 1943.7
- Avg. Page Density (full)................: 75.99%
DBCC SHOWCONTIG scanning 'dtproperties' table...
Table: 'dtproperties' (1451152215); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7567.0
- Avg. Page Density (full)................: 6.51%
DBCC SHOWCONTIG scanning 'Configuration' table...
Table: 'Configuration' (1573580644); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7290.0
- Avg. Page Density (full)................: 9.93%
DBCC SHOWCONTIG scanning 'Instruction' table...
Table: 'Instruction' (1605580758); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 4248.0
- Avg. Page Density (full)................: 47.52%
DBCC SHOWCONTIG scanning 'Message' table...
Table: 'Message' (1669580986); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 2
- Extents Scanned.......................: 2
- Extent Switches.......................: 1
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 50.00% [1:2]
- Logical Scan Fragmentation ..............: 50.00%
- Extent Scan Fragmentation ...............: 50.00%
- Avg. Bytes Free per Page................: 3633.0
- Avg. Page Density (full)................: 55.11%
DBCC SHOWCONTIG scanning 'SequenceNumbers' table...
Table: 'SequenceNumbers' (1765581328); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 6080.0
- Avg. Page Density (full)................: 24.88%
DBCC SHOWCONTIG scanning '_bufferlog' table...
Table: '_bufferlog' (1807306194); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 212
- Extents Scanned.......................: 31
- Extent Switches.......................: 30
- Avg. Pages per Extent..................: 6.8
- Scan Density [Best Count:Actual Count]......: 87.10% [27:31]
- Extent Scan Fragmentation ...............: 58.06%
- Avg. Bytes Free per Page................: 331.4
- Avg. Page Density (full)................: 95.91%
DBCC SHOWCONTIG scanning 'Technology' table...
Table: 'Technology' (1877581727); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7983.0
- Avg. Page Density (full)................: 1.37%
DBCC SHOWCONTIG scanning 'PostImportMap' table...
Table: 'PostImportMap' (1925581898); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7818.0
- Avg. Page Density (full)................: 3.41%
DBCC SHOWCONTIG scanning 'ImportErrors' table...
Table: 'ImportErrors' (1941581955); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7992.0
- Avg. Page Density (full)................: 1.26%
DBCC SHOWCONTIG scanning 'System' table...
Table: 'System' (2057058364); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 8077.0
- Avg. Page Density (full)................: 0.21%
DBCC SHOWCONTIG scanning 'WorkArea' table...
Table: 'WorkArea' (2089058478); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7970.0
- Avg. Page Density (full)................: 1.53%
DBCC SHOWCONTIG scanning 'ImportMap' table...
Table: 'ImportMap' (2112726579); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7742.0
- Avg. Page Density (full)................: 4.35%
DBCC SHOWCONTIG scanning 'QCCurrentActivity' table...
Table: 'QCCurrentActivity' (2116254644); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7940.0
- Avg. Page Density (full)................: 1.90%
DBCC SHOWCONTIG scanning 'Module' table...
Table: 'Module' (2137058649); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 6848.0
- Avg. Page Density (full)................: 15.39%
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Tracy McKibben wrote:
> Jayme wrote:
> > We have been running SQL Server 2000 on a production machine for years.
> > Within the last 6 months, we have noticed a performance problem. The
> > system will suddenly slow to a crawl. We run DBCC Reindex for all of
> > the tables in the our database, and things go back to normal - running
> > very quickly. We are currently having to do this multiple times a day.
> > We have verified the indexes are getting fragmented by using the DBCC
> > showcontig. What will cause the indexes to get fragmented so quickly?
> > How do we prevent this from happening?
> >
> > Any help would greatly be appreciated.
> > Thank you!
> > Jayme
> >
> Are you sure you're seeing index fragmentation, and not disk
> fragmentation? Post the output of your DBCC command..|||Jayme wrote:
> This is the dbcc output before the reindex is done:
>
Ahh yes, I see lots of high "Extent Scan Fragmentation" values,
indicating external fragmentation, i.e. DISK fragmentation:
http://www.sql-server-performance.com/rd_index_fragmentation.asp
Some things you can do:
1. Never shrink the database. It's going to grow again, and repeated
shrink/growth operations will cause disk fragmentation.
2. Size the database properly to accommodate your needs to several
months, to avoid auto-growth
3. After sizing the DB properly, schedule an outage where you can shut
down SQL Server and run a full disk defrag. Copy the database files
(mdf and ldf) to another volume, use the Windows defragger to defrag the
drive, then copy the data files back, one at a time.
4. Now that the external fragmentation has been resolved, rebuild the
indexes.|||Jayme wrote:
> OK, I defrag'd the disk. Rebuilt the indexes. It still looks like
> there is some extent fragmentation for some of the tables. The
> database is set up in 3 files, one for data, one for index, one for
> log. Could that cause it to show more extent fragmentation?
>
Having the indexes in a seperate file should not cause more
fragmentation, assuming the file is sized properly and is not
auto-growing or shrinking.
I have to ask, did you stop SQL Server before running your defrag? You
can't defrag the database files while SQL is running.|||Yes I stopped SQL Server.
Tracy McKibben wrote:
> Jayme wrote:
> > OK, I defrag'd the disk. Rebuilt the indexes. It still looks like
> > there is some extent fragmentation for some of the tables. The
> > database is set up in 3 files, one for data, one for index, one for
> > log. Could that cause it to show more extent fragmentation?
> >
> Having the indexes in a seperate file should not cause more
> fragmentation, assuming the file is sized properly and is not
> auto-growing or shrinking.
> I have to ask, did you stop SQL Server before running your defrag? You
> can't defrag the database files while SQL is running.|||Jayme wrote:
> Yes I stopped SQL Server.
>
You said you have seperate files for data, indexes, and logs. Is it
possible that these few indexes span multiple files, i.e. they share
space in your data file and the index file? Certain values reported by
SHOWCONTIG are unreliable in such cases.|||It is possible. We try to keep all the indexes in one file, but it
could happen.
Tracy McKibben wrote:
> Jayme wrote:
> > Yes I stopped SQL Server.
> >
> >
> You said you have seperate files for data, indexes, and logs. Is it
> possible that these few indexes span multiple files, i.e. they share
> space in your data file and the index file? Certain values reported by
> SHOWCONTIG are unreliable in such cases.|||Don't even bother about fragmentation unless the index has at least 1000
pages otherwise you're hardly going to notice a difference. form your
earlier output, none of your indexes have more than about 50 pages. The only
larger table you have is 'LineItem' and that's a heap so fragmentation is
irrelevant.
Why are you concerned about fragmentation?
--
Paul Randal
Lead Program Manager, Microsoft SQL Server Storage Engine
http://blogs.msdn.com/sqlserverstorageengine/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jayme" <jayloub@.comcast.net> wrote in message
news:1151071190.962959.17680@.i40g2000cwc.googlegroups.com...
> It is possible. We try to keep all the indexes in one file, but it
> could happen.
> Tracy McKibben wrote:
>> Jayme wrote:
>> > Yes I stopped SQL Server.
>> >
>> >
>> You said you have seperate files for data, indexes, and logs. Is it
>> possible that these few indexes span multiple files, i.e. they share
>> space in your data file and the index file? Certain values reported by
>> SHOWCONTIG are unreliable in such cases.
>|||It seems to have something to do with fragmentation of the indexes.
When we reindex the tables - the slowness immediately goes away.
What else could be happening that a reindex would fix?
Paul S Randal [MS] wrote:
> Don't even bother about fragmentation unless the index has at least 1000
> pages otherwise you're hardly going to notice a difference. form your
> earlier output, none of your indexes have more than about 50 pages. The only
> larger table you have is 'LineItem' and that's a heap so fragmentation is
> irrelevant.
> Why are you concerned about fragmentation?
> --
> Paul Randal
> Lead Program Manager, Microsoft SQL Server Storage Engine
> http://blogs.msdn.com/sqlserverstorageengine/default.aspx
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Jayme" <jayloub@.comcast.net> wrote in message
> news:1151071190.962959.17680@.i40g2000cwc.googlegroups.com...
> > It is possible. We try to keep all the indexes in one file, but it
> > could happen.
> >
> > Tracy McKibben wrote:
> >> Jayme wrote:
> >> > Yes I stopped SQL Server.
> >> >
> >> >
> >>
> >> You said you have seperate files for data, indexes, and logs. Is it
> >> possible that these few indexes span multiple files, i.e. they share
> >> space in your data file and the index file? Certain values reported by
> >> SHOWCONTIG are unreliable in such cases.
> >
Within the last 6 months, we have noticed a performance problem. The
system will suddenly slow to a crawl. We run DBCC Reindex for all of
the tables in the our database, and things go back to normal - running
very quickly. We are currently having to do this multiple times a day.
We have verified the indexes are getting fragmented by using the DBCC
showcontig. What will cause the indexes to get fragmented so quickly?
How do we prevent this from happening?
Any help would greatly be appreciated.
Thank you!
Jayme> What will cause the indexes to get fragmented so quickly?
Some possibilities:
Lots of inserts over a key that is no monotonically increasing.
Lost of updates (where value in index key changes).
Shrinking of database files.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Jayme" <jayloub@.comcast.net> wrote in message
news:1150568837.067145.140050@.c74g2000cwc.googlegroups.com...
> We have been running SQL Server 2000 on a production machine for years.
> Within the last 6 months, we have noticed a performance problem. The
> system will suddenly slow to a crawl. We run DBCC Reindex for all of
> the tables in the our database, and things go back to normal - running
> very quickly. We are currently having to do this multiple times a day.
> We have verified the indexes are getting fragmented by using the DBCC
> showcontig. What will cause the indexes to get fragmented so quickly?
> How do we prevent this from happening?
> Any help would greatly be appreciated.
> Thank you!
> Jayme
>|||Jayme wrote:
> We have been running SQL Server 2000 on a production machine for years.
> Within the last 6 months, we have noticed a performance problem. The
> system will suddenly slow to a crawl. We run DBCC Reindex for all of
> the tables in the our database, and things go back to normal - running
> very quickly. We are currently having to do this multiple times a day.
> We have verified the indexes are getting fragmented by using the DBCC
> showcontig. What will cause the indexes to get fragmented so quickly?
> How do we prevent this from happening?
> Any help would greatly be appreciated.
> Thank you!
> Jayme
>
Are you sure you're seeing index fragmentation, and not disk
fragmentation? Post the output of your DBCC command..|||Tracy McKibben wrote:
> Jayme wrote:
> > We have been running SQL Server 2000 on a production machine for years.
> > Within the last 6 months, we have noticed a performance problem. The
> > system will suddenly slow to a crawl. We run DBCC Reindex for all of
> > the tables in the our database, and things go back to normal - running
> > very quickly. We are currently having to do this multiple times a day.
> > We have verified the indexes are getting fragmented by using the DBCC
> > showcontig. What will cause the indexes to get fragmented so quickly?
> > How do we prevent this from happening?
> >
> > Any help would greatly be appreciated.
> > Thank you!
> > Jayme
> >
> Are you sure you're seeing index fragmentation, and not disk
> fragmentation? Post the output of your DBCC command..
Check out for disk fragmentation also.
If Index fragmentation , then BOL has very good sample, in DBCC
Showconting topic.
It will check index fragmentation and defrag index which are fragmented
below threshold value. Run it regularly.
Regards
Amish Shah|||This is the dbcc output before the reindex is done:
DBCC SHOWCONTIG scanning 'QCSKUTable' table...
Table: 'QCSKUTable' (32771224); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 533
- Extents Scanned.......................: 68
- Extent Switches.......................: 67
- Avg. Pages per Extent..................: 7.8
- Scan Density [Best Count:Actual Count]......: 98.53% [67:68]
- Logical Scan Fragmentation ..............: 9.01%
- Extent Scan Fragmentation ...............: 72.06%
- Avg. Bytes Free per Page................: 789.2
- Avg. Page Density (full)................: 90.25%
DBCC SHOWCONTIG scanning 'Map' table...
Table: 'Map' (101575400); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 6089.0
- Avg. Page Density (full)................: 24.77%
DBCC SHOWCONTIG scanning 'Zone' table...
Table: 'Zone' (133575514); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 70
- Extents Scanned.......................: 9
- Extent Switches.......................: 8
- Avg. Pages per Extent..................: 7.8
- Scan Density [Best Count:Actual Count]......: 100.00% [9:9]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 11.11%
- Avg. Bytes Free per Page................: 837.4
- Avg. Page Density (full)................: 89.65%
DBCC SHOWCONTIG scanning 'QCConfiguration' table...
Table: 'QCConfiguration' (192771794); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 6976.0
- Avg. Page Density (full)................: 13.81%
DBCC SHOWCONTIG scanning 'TestQCSKUTable' table...
Table: 'TestQCSKUTable' (230395990); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 535
- Extents Scanned.......................: 68
- Extent Switches.......................: 67
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 98.53% [67:68]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 67.65%
- Avg. Bytes Free per Page................: 786.5
- Avg. Page Density (full)................: 90.28%
DBCC SHOWCONTIG scanning 'Bay' table...
Table: 'Bay' (325576198); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 5
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 5.0
- Scan Density [Best Count:Actual Count]......: 100.00% [1:1]
- Logical Scan Fragmentation ..............: 20.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 2084.0
- Avg. Page Density (full)................: 74.25%
DBCC SHOWCONTIG scanning 'ZoneMap' table...
Table: 'ZoneMap' (357576312); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 309
- Extents Scanned.......................: 39
- Extent Switches.......................: 38
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 100.00% [39:39]
- Logical Scan Fragmentation ..............: 0.32%
- Extent Scan Fragmentation ...............: 69.23%
- Avg. Bytes Free per Page................: 799.9
- Avg. Page Density (full)................: 90.12%
DBCC SHOWCONTIG scanning 'Device' table...
Table: 'Device' (421576540); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 293
- Extents Scanned.......................: 37
- Extent Switches.......................: 36
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 100.00% [37:37]
- Logical Scan Fragmentation ..............: 0.34%
- Extent Scan Fragmentation ...............: 81.08%
- Avg. Bytes Free per Page................: 779.5
- Avg. Page Density (full)................: 90.37%
DBCC SHOWCONTIG scanning 'Location' table...
Table: 'Location' (501576825); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 285
- Extents Scanned.......................: 36
- Extent Switches.......................: 35
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 100.00% [36:36]
- Logical Scan Fragmentation ..............: 0.35%
- Extent Scan Fragmentation ...............: 5.56%
- Avg. Bytes Free per Page................: 786.2
- Avg. Page Density (full)................: 90.29%
DBCC SHOWCONTIG scanning 'Carrier' table...
Table: 'Carrier' (580913141); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 232
- Extents Scanned.......................: 34
- Extent Switches.......................: 33
- Avg. Pages per Extent..................: 6.8
- Scan Density [Best Count:Actual Count]......: 85.29% [29:34]
- Extent Scan Fragmentation ...............: 94.12%
- Avg. Bytes Free per Page................: 1359.3
- Avg. Page Density (full)................: 83.21%
DBCC SHOWCONTIG scanning 'NetController' table...
Table: 'NetController' (581577110); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 3
- Extent Switches.......................: 2
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 33.33% [1:3]
- Logical Scan Fragmentation ..............: 33.33%
- Extent Scan Fragmentation ...............: 33.33%
- Avg. Bytes Free per Page................: 1356.0
- Avg. Page Density (full)................: 83.25%
DBCC SHOWCONTIG scanning 'QCContentDetail' table...
Table: 'QCContentDetail' (596249229); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 8
- Extents Scanned.......................: 6
- Extent Switches.......................: 6
- Avg. Pages per Extent..................: 1.3
- Scan Density [Best Count:Actual Count]......: 14.29% [1:7]
- Logical Scan Fragmentation ..............: 50.00%
- Extent Scan Fragmentation ...............: 66.67%
- Avg. Bytes Free per Page................: 3306.5
- Avg. Page Density (full)................: 59.15%
DBCC SHOWCONTIG scanning 'OrderToCarrier' table...
Table: 'OrderToCarrier' (628913312); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 139
- Extents Scanned.......................: 31
- Extent Switches.......................: 30
- Avg. Pages per Extent..................: 4.5
- Scan Density [Best Count:Actual Count]......: 58.06% [18:31]
- Extent Scan Fragmentation ...............: 96.77%
- Avg. Bytes Free per Page................: 1491.1
- Avg. Page Density (full)................: 81.58%
DBCC SHOWCONTIG scanning 'WaveGroup' table...
Table: 'WaveGroup' (645577338); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7988.0
- Avg. Page Density (full)................: 1.31%
DBCC SHOWCONTIG scanning 'WorkLoadCriteriaDetail' table...
Table: 'WorkLoadCriteriaDetail' (654625375); index ID: 1, database ID:
6
TABLE level scan performed.
- Pages Scanned........................: 9
- Extents Scanned.......................: 2
- Extent Switches.......................: 1
- Avg. Pages per Extent..................: 4.5
- Scan Density [Best Count:Actual Count]......: 100.00% [2:2]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 970.7
- Avg. Page Density (full)................: 88.01%
DBCC SHOWCONTIG scanning 'Products' table...
Table: 'Products' (660913426); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 8056.0
- Avg. Page Density (full)................: 0.47%
DBCC SHOWCONTIG scanning 'CloseToteData' table...
Table: 'CloseToteData' (691025743); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 17307
- Extents Scanned.......................: 2167
- Extent Switches.......................: 2166
- Avg. Pages per Extent..................: 8.0
- Scan Density [Best Count:Actual Count]......: 99.86% [2164:2167]
- Extent Scan Fragmentation ...............: 18.00%
- Avg. Bytes Free per Page................: 356.5
- Avg. Page Density (full)................: 95.60%
DBCC SHOWCONTIG scanning 'OrderState' table...
Table: 'OrderState' (692913540); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7561.0
- Avg. Page Density (full)................: 6.59%
DBCC SHOWCONTIG scanning 'Wave' table...
Table: 'Wave' (709577566); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 4796.0
- Avg. Page Density (full)................: 40.75%
DBCC SHOWCONTIG scanning 'LNG' table...
Table: 'LNG' (715149593); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 25
- Extents Scanned.......................: 4
- Extent Switches.......................: 3
- Avg. Pages per Extent..................: 6.3
- Scan Density [Best Count:Actual Count]......: 100.00% [4:4]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 916.6
- Avg. Page Density (full)................: 88.68%
DBCC SHOWCONTIG scanning 'WaveState' table...
Table: 'WaveState' (724913654); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7659.0
- Avg. Page Density (full)................: 5.37%
DBCC SHOWCONTIG scanning 'PCS_Object' table...
Table: 'PCS_Object' (747149707); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 905.0
- Avg. Page Density (full)................: 88.82%
DBCC SHOWCONTIG scanning 'WaveByProduct' table...
Table: 'WaveByProduct' (756913768); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 8
- Extents Scanned.......................: 5
- Extent Switches.......................: 4
- Avg. Pages per Extent..................: 1.6
- Scan Density [Best Count:Actual Count]......: 20.00% [1:5]
- Extent Scan Fragmentation ...............: 80.00%
- Avg. Bytes Free per Page................: 7734.6
- Avg. Page Density (full)................: 4.44%
DBCC SHOWCONTIG scanning 'LineItem' table...
Table: 'LineItem' (762902235); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 5894
- Extents Scanned.......................: 745
- Extent Switches.......................: 744
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 98.93% [737:745]
- Extent Scan Fragmentation ...............: 89.13%
- Avg. Bytes Free per Page................: 1303.0
- Avg. Page Density (full)................: 83.90%
DBCC SHOWCONTIG scanning 'PCS_User' table...
Table: 'PCS_User' (779149821); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 3.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................: 1251.7
- Avg. Page Density (full)................: 84.54%
DBCC SHOWCONTIG scanning 'Wave' table...
Table: 'Wave' (788913882); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 8
- Extents Scanned.......................: 7
- Extent Switches.......................: 6
- Avg. Pages per Extent..................: 1.1
- Scan Density [Best Count:Actual Count]......: 14.29% [1:7]
- Extent Scan Fragmentation ...............: 57.14%
- Avg. Bytes Free per Page................: 7723.8
- Avg. Page Density (full)................: 4.57%
DBCC SHOWCONTIG scanning 'PDSynchronize' table...
Table: 'PDSynchronize' (794902349); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 3.0
- Scan Density [Best Count:Actual Count]......: 100.00% [1:1]
- Logical Scan Fragmentation ..............: 66.67%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 3770.7
- Avg. Page Density (full)................: 53.41%
DBCC SHOWCONTIG scanning 'PCS_PermissionGroup' table...
Table: 'PCS_PermissionGroup' (811149935); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7319.0
- Avg. Page Density (full)................: 9.57%
DBCC SHOWCONTIG scanning 'Order' table...
Table: 'Order' (836914053); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 364
- Extents Scanned.......................: 55
- Extent Switches.......................: 54
- Avg. Pages per Extent..................: 6.6
- Scan Density [Best Count:Actual Count]......: 83.64% [46:55]
- Extent Scan Fragmentation ...............: 98.18%
- Avg. Bytes Free per Page................: 1263.0
- Avg. Page Density (full)................: 84.40%
DBCC SHOWCONTIG scanning 'Task' table...
Table: 'Task' (837578022); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 296
- Extents Scanned.......................: 42
- Extent Switches.......................: 43
- Avg. Pages per Extent..................: 7.0
- Scan Density [Best Count:Actual Count]......: 84.09% [37:44]
- Logical Scan Fragmentation ..............: 0.68%
- Extent Scan Fragmentation ...............: 64.29%
- Avg. Bytes Free per Page................: 843.2
- Avg. Page Density (full)................: 89.58%
DBCC SHOWCONTIG scanning 'PCS_Component' table...
Table: 'PCS_Component' (843150049); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 5189.0
- Avg. Page Density (full)................: 35.89%
DBCC SHOWCONTIG scanning 'QCEventLog' table...
Table: 'QCEventLog' (843918128); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3603
- Extents Scanned.......................: 465
- Extent Switches.......................: 464
- Avg. Pages per Extent..................: 7.7
- Scan Density [Best Count:Actual Count]......: 96.99% [451:465]
- Extent Scan Fragmentation ...............: 36.99%
- Avg. Bytes Free per Page................: 575.1
- Avg. Page Density (full)................: 92.89%
DBCC SHOWCONTIG scanning 'OrderLine' table...
Table: 'OrderLine' (884914224); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 6298
- Extents Scanned.......................: 798
- Extent Switches.......................: 797
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 98.75% [788:798]
- Extent Scan Fragmentation ...............: 98.37%
- Avg. Bytes Free per Page................: 255.3
- Avg. Page Density (full)................: 96.85%
DBCC SHOWCONTIG scanning 'PCS_PermissionGroupHasPL1' table...
Table: 'PCS_PermissionGroupHasPL1' (891150220); index ID: 1, database
ID: 6
TABLE level scan performed.
- 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................: 2068.0
- Avg. Page Density (full)................: 74.45%
DBCC SHOWCONTIG scanning 'QCErrors' table...
Table: 'QCErrors' (923918413); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 10
- Extents Scanned.......................: 2
- Extent Switches.......................: 1
- Avg. Pages per Extent..................: 5.0
- Scan Density [Best Count:Actual Count]......: 100.00% [2:2]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 848.3
- Avg. Page Density (full)................: 89.52%
DBCC SHOWCONTIG scanning 'StateTransitionTimes' table...
Table: 'StateTransitionTimes' (932914395); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 590
- Extents Scanned.......................: 100
- Extent Switches.......................: 99
- Avg. Pages per Extent..................: 5.9
- Scan Density [Best Count:Actual Count]......: 74.00% [74:100]
- Extent Scan Fragmentation ...............: 91.00%
- Avg. Bytes Free per Page................: 599.8
- Avg. Page Density (full)................: 92.59%
DBCC SHOWCONTIG scanning 'PCS_UserInPermissionGroup' table...
Table: 'PCS_UserInPermissionGroup' (955150448); index ID: 1, database
ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 3
- Extent Switches.......................: 2
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 33.33% [1:3]
- Logical Scan Fragmentation ..............: 33.33%
- Extent Scan Fragmentation ...............: 66.67%
- Avg. Bytes Free per Page................: 869.0
- Avg. Page Density (full)................: 89.26%
DBCC SHOWCONTIG scanning 'PickMission' table...
Table: 'PickMission' (964914509); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 3950
- Extents Scanned.......................: 499
- Extent Switches.......................: 498
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 99.00% [494:499]
- Extent Scan Fragmentation ...............: 99.20%
- Avg. Bytes Free per Page................: 279.3
- Avg. Page Density (full)................: 96.55%
DBCC SHOWCONTIG scanning 'Mission' table...
Table: 'Mission' (965578478); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 346
- Extents Scanned.......................: 52
- Extent Switches.......................: 53
- Avg. Pages per Extent..................: 6.7
- Scan Density [Best Count:Actual Count]......: 81.48% [44:54]
- Logical Scan Fragmentation ..............: 1.16%
- Extent Scan Fragmentation ...............: 82.69%
- Avg. Bytes Free per Page................: 876.8
- Avg. Page Density (full)................: 89.17%
DBCC SHOWCONTIG scanning 'QCMasterList' table...
Table: 'QCMasterList' (1003918698); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 984
- Extents Scanned.......................: 128
- Extent Switches.......................: 133
- Avg. Pages per Extent..................: 7.7
- Scan Density [Best Count:Actual Count]......: 91.79% [123:134]
- Logical Scan Fragmentation ..............: 1.12%
- Extent Scan Fragmentation ...............: 64.06%
- Avg. Bytes Free per Page................: 753.2
- Avg. Page Density (full)................: 90.69%
DBCC SHOWCONTIG scanning 'PCS_Client' table...
Table: 'PCS_Client' (1019150676); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7427.0
- Avg. Page Density (full)................: 8.24%
DBCC SHOWCONTIG scanning 'PCS_ClientRestriction' table...
Table: 'PCS_ClientRestriction' (1051150790); index ID: 1, database ID:
6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7780.0
- Avg. Page Density (full)................: 3.88%
DBCC SHOWCONTIG scanning 'PickMissionComplete' table...
Table: 'PickMissionComplete' (1060914851); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 1661
- Extents Scanned.......................: 461
- Extent Switches.......................: 460
- Avg. Pages per Extent..................: 3.6
- Scan Density [Best Count:Actual Count]......: 45.12% [208:461]
- Extent Scan Fragmentation ...............: 66.81%
- Avg. Bytes Free per Page................: 2926.2
- Avg. Page Density (full)................: 63.85%
DBCC SHOWCONTIG scanning 'UISCFG_Band' table...
Table: 'UISCFG_Band' (1083150904); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 6640.0
- Avg. Page Density (full)................: 17.96%
DBCC SHOWCONTIG scanning 'CurrentActivity' table...
Table: 'CurrentActivity' (1093578934); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 743.0
- Avg. Page Density (full)................: 90.82%
DBCC SHOWCONTIG scanning 'UISCFG_ComponentEntry' table...
Table: 'UISCFG_ComponentEntry' (1115151018); index ID: 1, database ID:
6
TABLE level scan performed.
- Pages Scanned........................: 2
- Extents Scanned.......................: 1
- Extent Switches.......................: 0
- Avg. Pages per Extent..................: 2.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................: 816.0
- Avg. Page Density (full)................: 89.92%
DBCC SHOWCONTIG scanning 'Configuration' table...
Table: 'Configuration' (1156915193); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7690.0
- Avg. Page Density (full)................: 4.99%
DBCC SHOWCONTIG scanning 'UISCFG_CE_on_Band' table...
Table: 'UISCFG_CE_on_Band' (1163151189); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 4881.0
- Avg. Page Density (full)................: 39.70%
DBCC SHOWCONTIG scanning 'UISCFG_Treeview' table...
Table: 'UISCFG_Treeview' (1227151417); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 3117.0
- Avg. Page Density (full)................: 61.49%
DBCC SHOWCONTIG scanning 'UISCFG_Events' table...
Table: 'UISCFG_Events' (1307151702); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 8051.0
- Avg. Page Density (full)................: 0.53%
DBCC SHOWCONTIG scanning 'IAS_AutoInteraction' table...
Table: 'IAS_AutoInteraction' (1323151759); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 2797.0
- Avg. Page Density (full)................: 65.44%
DBCC SHOWCONTIG scanning 'WorkLoadRollup' table...
Table: 'WorkLoadRollup' (1332199796); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 2370
- Extents Scanned.......................: 298
- Extent Switches.......................: 297
- Avg. Pages per Extent..................: 8.0
- Scan Density [Best Count:Actual Count]......: 99.66% [297:298]
- Logical Scan Fragmentation ..............: 9.66%
- Extent Scan Fragmentation ...............: 61.07%
- Avg. Bytes Free per Page................: 696.5
- Avg. Page Density (full)................: 91.39%
DBCC SHOWCONTIG scanning 'MissionDetail' table...
Table: 'MissionDetail' (1349579846); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 1494
- Extents Scanned.......................: 189
- Extent Switches.......................: 855
- Avg. Pages per Extent..................: 7.9
- Scan Density [Best Count:Actual Count]......: 21.85% [187:856]
- Logical Scan Fragmentation ..............: 27.58%
- Extent Scan Fragmentation ...............: 89.42%
- Avg. Bytes Free per Page................: 4327.5
- Avg. Page Density (full)................: 46.54%
DBCC SHOWCONTIG scanning 'UISCFG_SystemParameters' table...
Table: 'UISCFG_SystemParameters' (1355151873); index ID: 1, database
ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7984.0
- Avg. Page Density (full)................: 1.36%
DBCC SHOWCONTIG scanning 'UISCFG_ProductInfo' table...
Table: 'UISCFG_ProductInfo' (1387151987); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 8048.0
- Avg. Page Density (full)................: 0.57%
DBCC SHOWCONTIG scanning 'UISCFG_UserPreferences' table...
Table: 'UISCFG_UserPreferences' (1419152101); index ID: 1, database ID:
6
TABLE level scan performed.
- Pages Scanned........................: 3
- Extents Scanned.......................: 3
- Extent Switches.......................: 2
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 33.33% [1:3]
- Logical Scan Fragmentation ..............: 0.00%
- Extent Scan Fragmentation ...............: 66.67%
- Avg. Bytes Free per Page................: 1943.7
- Avg. Page Density (full)................: 75.99%
DBCC SHOWCONTIG scanning 'dtproperties' table...
Table: 'dtproperties' (1451152215); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7567.0
- Avg. Page Density (full)................: 6.51%
DBCC SHOWCONTIG scanning 'Configuration' table...
Table: 'Configuration' (1573580644); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7290.0
- Avg. Page Density (full)................: 9.93%
DBCC SHOWCONTIG scanning 'Instruction' table...
Table: 'Instruction' (1605580758); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 4248.0
- Avg. Page Density (full)................: 47.52%
DBCC SHOWCONTIG scanning 'Message' table...
Table: 'Message' (1669580986); index ID: 1, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 2
- Extents Scanned.......................: 2
- Extent Switches.......................: 1
- Avg. Pages per Extent..................: 1.0
- Scan Density [Best Count:Actual Count]......: 50.00% [1:2]
- Logical Scan Fragmentation ..............: 50.00%
- Extent Scan Fragmentation ...............: 50.00%
- Avg. Bytes Free per Page................: 3633.0
- Avg. Page Density (full)................: 55.11%
DBCC SHOWCONTIG scanning 'SequenceNumbers' table...
Table: 'SequenceNumbers' (1765581328); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 6080.0
- Avg. Page Density (full)................: 24.88%
DBCC SHOWCONTIG scanning '_bufferlog' table...
Table: '_bufferlog' (1807306194); index ID: 0, database ID: 6
TABLE level scan performed.
- Pages Scanned........................: 212
- Extents Scanned.......................: 31
- Extent Switches.......................: 30
- Avg. Pages per Extent..................: 6.8
- Scan Density [Best Count:Actual Count]......: 87.10% [27:31]
- Extent Scan Fragmentation ...............: 58.06%
- Avg. Bytes Free per Page................: 331.4
- Avg. Page Density (full)................: 95.91%
DBCC SHOWCONTIG scanning 'Technology' table...
Table: 'Technology' (1877581727); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7983.0
- Avg. Page Density (full)................: 1.37%
DBCC SHOWCONTIG scanning 'PostImportMap' table...
Table: 'PostImportMap' (1925581898); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7818.0
- Avg. Page Density (full)................: 3.41%
DBCC SHOWCONTIG scanning 'ImportErrors' table...
Table: 'ImportErrors' (1941581955); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7992.0
- Avg. Page Density (full)................: 1.26%
DBCC SHOWCONTIG scanning 'System' table...
Table: 'System' (2057058364); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 8077.0
- Avg. Page Density (full)................: 0.21%
DBCC SHOWCONTIG scanning 'WorkArea' table...
Table: 'WorkArea' (2089058478); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 7970.0
- Avg. Page Density (full)................: 1.53%
DBCC SHOWCONTIG scanning 'ImportMap' table...
Table: 'ImportMap' (2112726579); index ID: 0, database ID: 6
TABLE level scan performed.
- 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]
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7742.0
- Avg. Page Density (full)................: 4.35%
DBCC SHOWCONTIG scanning 'QCCurrentActivity' table...
Table: 'QCCurrentActivity' (2116254644); index ID: 1, database ID: 6
TABLE level scan performed.
- 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 ..............: 100.00%
- Extent Scan Fragmentation ...............: 0.00%
- Avg. Bytes Free per Page................: 7940.0
- Avg. Page Density (full)................: 1.90%
DBCC SHOWCONTIG scanning 'Module' table...
Table: 'Module' (2137058649); index ID: 1, database ID: 6
TABLE level scan performed.
- 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................: 6848.0
- Avg. Page Density (full)................: 15.39%
DBCC execution completed. If DBCC printed error messages, contact your
system administrator.
Tracy McKibben wrote:
> Jayme wrote:
> > We have been running SQL Server 2000 on a production machine for years.
> > Within the last 6 months, we have noticed a performance problem. The
> > system will suddenly slow to a crawl. We run DBCC Reindex for all of
> > the tables in the our database, and things go back to normal - running
> > very quickly. We are currently having to do this multiple times a day.
> > We have verified the indexes are getting fragmented by using the DBCC
> > showcontig. What will cause the indexes to get fragmented so quickly?
> > How do we prevent this from happening?
> >
> > Any help would greatly be appreciated.
> > Thank you!
> > Jayme
> >
> Are you sure you're seeing index fragmentation, and not disk
> fragmentation? Post the output of your DBCC command..|||Jayme wrote:
> This is the dbcc output before the reindex is done:
>
Ahh yes, I see lots of high "Extent Scan Fragmentation" values,
indicating external fragmentation, i.e. DISK fragmentation:
http://www.sql-server-performance.com/rd_index_fragmentation.asp
Some things you can do:
1. Never shrink the database. It's going to grow again, and repeated
shrink/growth operations will cause disk fragmentation.
2. Size the database properly to accommodate your needs to several
months, to avoid auto-growth
3. After sizing the DB properly, schedule an outage where you can shut
down SQL Server and run a full disk defrag. Copy the database files
(mdf and ldf) to another volume, use the Windows defragger to defrag the
drive, then copy the data files back, one at a time.
4. Now that the external fragmentation has been resolved, rebuild the
indexes.|||Jayme wrote:
> OK, I defrag'd the disk. Rebuilt the indexes. It still looks like
> there is some extent fragmentation for some of the tables. The
> database is set up in 3 files, one for data, one for index, one for
> log. Could that cause it to show more extent fragmentation?
>
Having the indexes in a seperate file should not cause more
fragmentation, assuming the file is sized properly and is not
auto-growing or shrinking.
I have to ask, did you stop SQL Server before running your defrag? You
can't defrag the database files while SQL is running.|||Yes I stopped SQL Server.
Tracy McKibben wrote:
> Jayme wrote:
> > OK, I defrag'd the disk. Rebuilt the indexes. It still looks like
> > there is some extent fragmentation for some of the tables. The
> > database is set up in 3 files, one for data, one for index, one for
> > log. Could that cause it to show more extent fragmentation?
> >
> Having the indexes in a seperate file should not cause more
> fragmentation, assuming the file is sized properly and is not
> auto-growing or shrinking.
> I have to ask, did you stop SQL Server before running your defrag? You
> can't defrag the database files while SQL is running.|||Jayme wrote:
> Yes I stopped SQL Server.
>
You said you have seperate files for data, indexes, and logs. Is it
possible that these few indexes span multiple files, i.e. they share
space in your data file and the index file? Certain values reported by
SHOWCONTIG are unreliable in such cases.|||It is possible. We try to keep all the indexes in one file, but it
could happen.
Tracy McKibben wrote:
> Jayme wrote:
> > Yes I stopped SQL Server.
> >
> >
> You said you have seperate files for data, indexes, and logs. Is it
> possible that these few indexes span multiple files, i.e. they share
> space in your data file and the index file? Certain values reported by
> SHOWCONTIG are unreliable in such cases.|||Don't even bother about fragmentation unless the index has at least 1000
pages otherwise you're hardly going to notice a difference. form your
earlier output, none of your indexes have more than about 50 pages. The only
larger table you have is 'LineItem' and that's a heap so fragmentation is
irrelevant.
Why are you concerned about fragmentation?
--
Paul Randal
Lead Program Manager, Microsoft SQL Server Storage Engine
http://blogs.msdn.com/sqlserverstorageengine/default.aspx
This posting is provided "AS IS" with no warranties, and confers no rights.
"Jayme" <jayloub@.comcast.net> wrote in message
news:1151071190.962959.17680@.i40g2000cwc.googlegroups.com...
> It is possible. We try to keep all the indexes in one file, but it
> could happen.
> Tracy McKibben wrote:
>> Jayme wrote:
>> > Yes I stopped SQL Server.
>> >
>> >
>> You said you have seperate files for data, indexes, and logs. Is it
>> possible that these few indexes span multiple files, i.e. they share
>> space in your data file and the index file? Certain values reported by
>> SHOWCONTIG are unreliable in such cases.
>|||It seems to have something to do with fragmentation of the indexes.
When we reindex the tables - the slowness immediately goes away.
What else could be happening that a reindex would fix?
Paul S Randal [MS] wrote:
> Don't even bother about fragmentation unless the index has at least 1000
> pages otherwise you're hardly going to notice a difference. form your
> earlier output, none of your indexes have more than about 50 pages. The only
> larger table you have is 'LineItem' and that's a heap so fragmentation is
> irrelevant.
> Why are you concerned about fragmentation?
> --
> Paul Randal
> Lead Program Manager, Microsoft SQL Server Storage Engine
> http://blogs.msdn.com/sqlserverstorageengine/default.aspx
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Jayme" <jayloub@.comcast.net> wrote in message
> news:1151071190.962959.17680@.i40g2000cwc.googlegroups.com...
> > It is possible. We try to keep all the indexes in one file, but it
> > could happen.
> >
> > Tracy McKibben wrote:
> >> Jayme wrote:
> >> > Yes I stopped SQL Server.
> >> >
> >> >
> >>
> >> You said you have seperate files for data, indexes, and logs. Is it
> >> possible that these few indexes span multiple files, i.e. they share
> >> space in your data file and the index file? Certain values reported by
> >> SHOWCONTIG are unreliable in such cases.
> >
Subscribe to:
Posts (Atom)