Hi,
I'm building a search engine for a website using sql server 2000 (sp3).
My development invironment is Windows XP Pro and the production server
is Windows 2003, and I'm getting the same problem on both machines.
I have two tables in the cataolg, one contaning only text fields
(varchar and ntext). The results come out great for this table, no
problem here. The second table has an image field that can contain just
about any kind of documents: .txt, .doc, .pdf, .xls, .mpg, .zip, etc.
And this image column can sometimes be empty for cetain records. There's
also a column indicating the file type and I'm using the file extension
for this. I wasn't sure what to put here I tried the mime type, the
extension, with and without the period this never changed anything. I
read somewhere that it should be the file extension with the period so
I've set it back to that.
I've done a lot of searching and reading in the past few days but can't
find the problem. I've tryed searches on various types of documents,
including .txt, .doc and .pdf. I'm not absolutely sure but I think my
image column is't being indexed at all; this same table also has a
"title" and "description" field included in the index and if I search
for text contained in either of those 2 columns they turn up in the results.
Any ideas?
Any help would be much appreciated.
tia
Lucas,
Yes. First of all, could you post the full output of -- SELECT @.@.version --
as well as the table schema of both your tables (via sp_help <table_name>)
as will help in understanding your environment. The datatype, size and
nullablity of the "file extension" column is very important in getting this
to work correctly. You can include or exclude the "." period when populating
the values in your "file extension" column, but then you will need to define
it as a varchar(4) or you can use the sysname datatype.
As you second table contains an image column and the "file extension"
column, it can only hold binary file types, such as doc, .pdf, .xls, .mpg,
..zip, but not .txt. For text (.txt) files, you must store this type file in
a Text or NText datatype as the pure text will be FT Indexed without the
file extension. For non-MS Office file types, such as Adobe PDF, MPG and ZIP
files, you will need to install 3rd party IFilters that support these file
types, these can be downloaded from:
Adobe PDF IFilter v6.0:
http://www.adobe.com/support/downloa...11&fileID=2457
Zip IFilter:
http://www.ifiltershop.com/zipfilter.html
Zip IFilter:
http://www.4-share.com/
mp3 (MEPG) IFilter
http://www.meticulus.com/mp3filter.html
Microsoft Office file types (.doc, .xls, .ppt) and text (.txt) and HTML
(.htm) files are FT Indexed out-of-the-box by SQL Server 2000. See SQL
Server 2000 BOL title "Filtering Supported File Types" from more info.
Finally, you should always review the server's Application event log for
information on the success &/or failure of FT Indexing specific file types.
Regards,
John
SQL Full Text Search Blog
http://spaces.msn.com/members/jtkane/
"lucas" <lucarc@.hotmail.qc> wrote in message
news:xgXDd.32709$Y61.1126448@.wagner.videotron.net. ..
> Hi,
> I'm building a search engine for a website using sql server 2000 (sp3).
> My development invironment is Windows XP Pro and the production server
> is Windows 2003, and I'm getting the same problem on both machines.
> I have two tables in the cataolg, one contaning only text fields
> (varchar and ntext). The results come out great for this table, no
> problem here. The second table has an image field that can contain just
> about any kind of documents: .txt, .doc, .pdf, .xls, .mpg, .zip, etc.
> And this image column can sometimes be empty for cetain records. There's
> also a column indicating the file type and I'm using the file extension
> for this. I wasn't sure what to put here I tried the mime type, the
> extension, with and without the period this never changed anything. I
> read somewhere that it should be the file extension with the period so
> I've set it back to that.
> I've done a lot of searching and reading in the past few days but can't
> find the problem. I've tryed searches on various types of documents,
> including .txt, .doc and .pdf. I'm not absolutely sure but I think my
> image column is't being indexed at all; this same table also has a
> "title" and "description" field included in the index and if I search
> for text contained in either of those 2 columns they turn up in the
results.
> Any ideas?
> Any help would be much appreciated.
> tia
|||Hi John,
Thanks for your response. I finally got it to work; it was nothing more
than an error in my query, I wasn't actualy ever searching my image
column.....d'oh!
It's working fine now.
Showing posts with label production. Show all posts
Showing posts with label production. Show all posts
Monday, March 19, 2012
Indexing Huge Table
Well i have a database on my production server which is containing a table
having 10 million records and daily 10 - 20 K records are being inserted int
o
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please helpAmit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
You don't need to reindex for new rows. They are automatically added to
indexes on the table when the row is added/updated/deleted.
I'm guessing this table is used in a DSS scenario and that's the reason
for all the indexing. Without knowing more about your environment and
how the table is used, it's hard to recommend options other than to say
you may want the clustered index on the table to be on a key(s) that
won't cause too much page splitting. But, then again, for DSS it may be
better to have the clustered index on a set of keys that benefits
queries.
If you need to reindex then you should do this off-hours. Rebuilding the
clustered index will cause a non-clustered rebuild as well. You can also
defrag tables/indexes using DBCC INDEXDEFRAG.
David Gugick
Imceda Software
www.imceda.com|||Amit,
Have a look into the below article. This is really great.
http://www.microsoft.com/technet/pr...n/ss2kidbp.mspx
Thanks
Hari
SQL Server MVP
"Amit Patel" wrote:
> Well i have a database on my production server which is containing a table
> having 10 million records and daily 10 - 20 K records are being inserted i
nto
> the same. The Table is also containing 25 indexes on different columns so
> which is best time and way to reindex my table for newly inserted records
.
> Please help
having 10 million records and daily 10 - 20 K records are being inserted int
o
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please helpAmit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
You don't need to reindex for new rows. They are automatically added to
indexes on the table when the row is added/updated/deleted.
I'm guessing this table is used in a DSS scenario and that's the reason
for all the indexing. Without knowing more about your environment and
how the table is used, it's hard to recommend options other than to say
you may want the clustered index on the table to be on a key(s) that
won't cause too much page splitting. But, then again, for DSS it may be
better to have the clustered index on a set of keys that benefits
queries.
If you need to reindex then you should do this off-hours. Rebuilding the
clustered index will cause a non-clustered rebuild as well. You can also
defrag tables/indexes using DBCC INDEXDEFRAG.
David Gugick
Imceda Software
www.imceda.com|||Amit,
Have a look into the below article. This is really great.
http://www.microsoft.com/technet/pr...n/ss2kidbp.mspx
Thanks
Hari
SQL Server MVP
"Amit Patel" wrote:
> Well i have a database on my production server which is containing a table
> having 10 million records and daily 10 - 20 K records are being inserted i
nto
> the same. The Table is also containing 25 indexes on different columns so
> which is best time and way to reindex my table for newly inserted records
.
> Please help
Indexing Huge Table
Well i have a database on my production server which is containing a table
having 10 million records and daily 10 - 20 K records are being inserted into
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please helpAmit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
You don't need to reindex for new rows. They are automatically added to
indexes on the table when the row is added/updated/deleted.
I'm guessing this table is used in a DSS scenario and that's the reason
for all the indexing. Without knowing more about your environment and
how the table is used, it's hard to recommend options other than to say
you may want the clustered index on the table to be on a key(s) that
won't cause too much page splitting. But, then again, for DSS it may be
better to have the clustered index on a set of keys that benefits
queries.
If you need to reindex then you should do this off-hours. Rebuilding the
clustered index will cause a non-clustered rebuild as well. You can also
defrag tables/indexes using DBCC INDEXDEFRAG.
David Gugick
Imceda Software
www.imceda.com|||Amit,
Have a look into the below article. This is really great.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx
Thanks
Hari
SQL Server MVP
"Amit Patel" wrote:
> Well i have a database on my production server which is containing a table
> having 10 million records and daily 10 - 20 K records are being inserted into
> the same. The Table is also containing 25 indexes on different columns so
> which is best time and way to reindex my table for newly inserted records.
> Please help
having 10 million records and daily 10 - 20 K records are being inserted into
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please helpAmit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
You don't need to reindex for new rows. They are automatically added to
indexes on the table when the row is added/updated/deleted.
I'm guessing this table is used in a DSS scenario and that's the reason
for all the indexing. Without knowing more about your environment and
how the table is used, it's hard to recommend options other than to say
you may want the clustered index on the table to be on a key(s) that
won't cause too much page splitting. But, then again, for DSS it may be
better to have the clustered index on a set of keys that benefits
queries.
If you need to reindex then you should do this off-hours. Rebuilding the
clustered index will cause a non-clustered rebuild as well. You can also
defrag tables/indexes using DBCC INDEXDEFRAG.
David Gugick
Imceda Software
www.imceda.com|||Amit,
Have a look into the below article. This is really great.
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/ss2kidbp.mspx
Thanks
Hari
SQL Server MVP
"Amit Patel" wrote:
> Well i have a database on my production server which is containing a table
> having 10 million records and daily 10 - 20 K records are being inserted into
> the same. The Table is also containing 25 indexes on different columns so
> which is best time and way to reindex my table for newly inserted records.
> Please help
Indexing Huge Table
Well i have a database on my production server which is containing a table
having 10 million records and daily 10 - 20 K records are being inserted into
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please help
Amit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
You don't need to reindex for new rows. They are automatically added to
indexes on the table when the row is added/updated/deleted.
I'm guessing this table is used in a DSS scenario and that's the reason
for all the indexing. Without knowing more about your environment and
how the table is used, it's hard to recommend options other than to say
you may want the clustered index on the table to be on a key(s) that
won't cause too much page splitting. But, then again, for DSS it may be
better to have the clustered index on a set of keys that benefits
queries.
If you need to reindex then you should do this off-hours. Rebuilding the
clustered index will cause a non-clustered rebuild as well. You can also
defrag tables/indexes using DBCC INDEXDEFRAG.
David Gugick
Imceda Software
www.imceda.com
|||Amit,
Have a look into the below article. This is really great.
http://www.microsoft.com/technet/pro.../ss2kidbp.mspx
Thanks
Hari
SQL Server MVP
"Amit Patel" wrote:
> Well i have a database on my production server which is containing a table
> having 10 million records and daily 10 - 20 K records are being inserted into
> the same. The Table is also containing 25 indexes on different columns so
> which is best time and way to reindex my table for newly inserted records.
> Please help
having 10 million records and daily 10 - 20 K records are being inserted into
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please help
Amit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
You don't need to reindex for new rows. They are automatically added to
indexes on the table when the row is added/updated/deleted.
I'm guessing this table is used in a DSS scenario and that's the reason
for all the indexing. Without knowing more about your environment and
how the table is used, it's hard to recommend options other than to say
you may want the clustered index on the table to be on a key(s) that
won't cause too much page splitting. But, then again, for DSS it may be
better to have the clustered index on a set of keys that benefits
queries.
If you need to reindex then you should do this off-hours. Rebuilding the
clustered index will cause a non-clustered rebuild as well. You can also
defrag tables/indexes using DBCC INDEXDEFRAG.
David Gugick
Imceda Software
www.imceda.com
|||Amit,
Have a look into the below article. This is really great.
http://www.microsoft.com/technet/pro.../ss2kidbp.mspx
Thanks
Hari
SQL Server MVP
"Amit Patel" wrote:
> Well i have a database on my production server which is containing a table
> having 10 million records and daily 10 - 20 K records are being inserted into
> the same. The Table is also containing 25 indexes on different columns so
> which is best time and way to reindex my table for newly inserted records.
> Please help
Indexing Huge Table
Well i have a database on my production server which is containing a table
having 10 million records and daily 10 - 20 K records are being inserted int
o
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please helpAmit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
multi-post. see response in other ng.
David Gugick
Imceda Software
www.imceda.com
having 10 million records and daily 10 - 20 K records are being inserted int
o
the same. The Table is also containing 25 indexes on different columns so
which is best time and way to reindex my table for newly inserted records.
Please helpAmit Patel wrote:
> Well i have a database on my production server which is containing a
> table having 10 million records and daily 10 - 20 K records are being
> inserted into the same. The Table is also containing 25 indexes on
> different columns so which is best time and way to reindex my table
> for newly inserted records.
> Please help
multi-post. see response in other ng.
David Gugick
Imceda Software
www.imceda.com
Wednesday, March 7, 2012
Indexes not rebuilding on SQL 2K DB MAINT PLAN
I see errors in my DB Maint log that indicates indexes are not being rebuilt.
We are having production problems - time outs. Does the optimization plan
for DB Maintenence drop bad indexes - simply put, what is my best way to
handle back indexes on a production server?
--
Regards,
JamieError is:
Backup can not be performed on this database. This sub task is ignored
--
Regards,
Jamie
"thejamie" wrote:
> I see errors in my DB Maint log that indicates indexes are not being rebuilt.
> We are having production problems - time outs. Does the optimization plan
> for DB Maintenence drop bad indexes - simply put, what is my best way to
> handle back indexes on a production server?
> --
> Regards,
> Jamie|||thejamie wrote:
> Error is:
> Backup can not be performed on this database. This sub task is ignored
That has nothing to do with indexes... This error is telling you that
you are attempting to do a transaction log backup against a database
that is in Simple recovery mode.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||That particular database is a production database. Why would it be in simple
recovery mode?
--
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> > Error is:
> > Backup can not be performed on this database. This sub task is ignored
> That has nothing to do with indexes... This error is telling you that
> you are attempting to do a transaction log backup against a database
> that is in Simple recovery mode.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||thejamie wrote:
> That particular database is a production database. Why would it be in simple
> recovery mode?
Only you can answer that question...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Can you give me a hint on this... it appears to be in normal mode - not
recovery mode.
--
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> > That particular database is a production database. Why would it be in simple
> > recovery mode?
> Only you can answer that question...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Open the database property window, select the option tab and check what
recovery mode your database on
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
>> thejamie wrote:
>> > That particular database is a production database. Why would it be in
>> > simple
>> > recovery mode?
>> Only you can answer that question...
>>
>> --
>> Tracy McKibben
>> MCDBA
>> http://www.realsqlguy.com|||Does your maintenance plan include master databases, if so remove it from ur
maintenance plan darabase list..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
>> thejamie wrote:
>> > That particular database is a production database. Why would it be in
>> > simple
>> > recovery mode?
>> Only you can answer that question...
>>
>> --
>> Tracy McKibben
>> MCDBA
>> http://www.realsqlguy.com|||Thanks. I am in simple recovery mode. I would like to know I can run a
point in time restore. Do I need to switch to FULL recovery mode for this?
--
Regards,
Jamie
"vt" wrote:
> Does your maintenance plan include master databases, if so remove it from ur
> maintenance plan darabase list..
> vinu
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> > Can you give me a hint on this... it appears to be in normal mode - not
> > recovery mode.
> > --
> > Regards,
> > Jamie
> >
> >
> > "Tracy McKibben" wrote:
> >
> >> thejamie wrote:
> >> > That particular database is a production database. Why would it be in
> >> > simple
> >> > recovery mode?
> >>
> >> Only you can answer that question...
> >>
> >>
> >> --
> >> Tracy McKibben
> >> MCDBA
> >> http://www.realsqlguy.com
> >>
>
>|||With simple recovery mode you will not be able to do point in time restore
read BOL (Book online) for more detail..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> Thanks. I am in simple recovery mode. I would like to know I can run a
> point in time restore. Do I need to switch to FULL recovery mode for
> this?
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> Does your maintenance plan include master databases, if so remove it from
>> ur
>> maintenance plan darabase list..
>> vinu
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> > Can you give me a hint on this... it appears to be in normal mode - not
>> > recovery mode.
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "Tracy McKibben" wrote:
>> >
>> >> thejamie wrote:
>> >> > That particular database is a production database. Why would it be
>> >> > in
>> >> > simple
>> >> > recovery mode?
>> >>
>> >> Only you can answer that question...
>> >>
>> >>
>> >> --
>> >> Tracy McKibben
>> >> MCDBA
>> >> http://www.realsqlguy.com
>> >>
>>|||Yes. That's right. Will the server need anything more than a reboot to
enter full recovery mode?
--
Regards,
Jamie
"vt" wrote:
> With simple recovery mode you will not be able to do point in time restore
> read BOL (Book online) for more detail..
> vinu
>
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> > Thanks. I am in simple recovery mode. I would like to know I can run a
> > point in time restore. Do I need to switch to FULL recovery mode for
> > this?
> > --
> > Regards,
> > Jamie
> >
> >
> > "vt" wrote:
> >
> >> Does your maintenance plan include master databases, if so remove it from
> >> ur
> >> maintenance plan darabase list..
> >> vinu
> >>
> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> >> > Can you give me a hint on this... it appears to be in normal mode - not
> >> > recovery mode.
> >> > --
> >> > Regards,
> >> > Jamie
> >> >
> >> >
> >> > "Tracy McKibben" wrote:
> >> >
> >> >> thejamie wrote:
> >> >> > That particular database is a production database. Why would it be
> >> >> > in
> >> >> > simple
> >> >> > recovery mode?
> >> >>
> >> >> Only you can answer that question...
> >> >>
> >> >>
> >> >> --
> >> >> Tracy McKibben
> >> >> MCDBA
> >> >> http://www.realsqlguy.com
> >> >>
> >>
> >>
> >>
>
>|||Hi Jamie
You don't even need to reboot. Just change to FULL, then make a full db
backup.
From that point on, you will be able to make log backups, and use them to
restore to a specific point in time, when necessary.
Please read the documentation on log backups and recovery models.
--
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> Yes. That's right. Will the server need anything more than a reboot to
> enter full recovery mode?
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> With simple recovery mode you will not be able to do point in time
>> restore
>> read BOL (Book online) for more detail..
>> vinu
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> > Thanks. I am in simple recovery mode. I would like to know I can
>> > run a
>> > point in time restore. Do I need to switch to FULL recovery mode for
>> > this?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> Does your maintenance plan include master databases, if so remove it
>> >> from
>> >> ur
>> >> maintenance plan darabase list..
>> >> vinu
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> > Can you give me a hint on this... it appears to be in normal mode -
>> >> > not
>> >> > recovery mode.
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "Tracy McKibben" wrote:
>> >> >
>> >> >> thejamie wrote:
>> >> >> > That particular database is a production database. Why would it
>> >> >> > be
>> >> >> > in
>> >> >> > simple
>> >> >> > recovery mode?
>> >> >>
>> >> >> Only you can answer that question...
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Tracy McKibben
>> >> >> MCDBA
>> >> >> http://www.realsqlguy.com
>> >> >>
>> >>
>> >>
>> >>
>>|||I don't think server will ask you to reboot
go ahead
vt
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> Yes. That's right. Will the server need anything more than a reboot to
> enter full recovery mode?
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> With simple recovery mode you will not be able to do point in time
>> restore
>> read BOL (Book online) for more detail..
>> vinu
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> > Thanks. I am in simple recovery mode. I would like to know I can
>> > run a
>> > point in time restore. Do I need to switch to FULL recovery mode for
>> > this?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> Does your maintenance plan include master databases, if so remove it
>> >> from
>> >> ur
>> >> maintenance plan darabase list..
>> >> vinu
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> > Can you give me a hint on this... it appears to be in normal mode -
>> >> > not
>> >> > recovery mode.
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "Tracy McKibben" wrote:
>> >> >
>> >> >> thejamie wrote:
>> >> >> > That particular database is a production database. Why would it
>> >> >> > be
>> >> >> > in
>> >> >> > simple
>> >> >> > recovery mode?
>> >> >>
>> >> >> Only you can answer that question...
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Tracy McKibben
>> >> >> MCDBA
>> >> >> http://www.realsqlguy.com
>> >> >>
>> >>
>> >>
>> >>
>>|||Thanks to all of you. This is a big load off my mind.
--
Regards,
Jamie
"vt" wrote:
> I don't think server will ask you to reboot
> go ahead
> vt
>
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> > Yes. That's right. Will the server need anything more than a reboot to
> > enter full recovery mode?
> > --
> > Regards,
> > Jamie
> >
> >
> > "vt" wrote:
> >
> >> With simple recovery mode you will not be able to do point in time
> >> restore
> >> read BOL (Book online) for more detail..
> >>
> >> vinu
> >>
> >>
> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> >> > Thanks. I am in simple recovery mode. I would like to know I can
> >> > run a
> >> > point in time restore. Do I need to switch to FULL recovery mode for
> >> > this?
> >> > --
> >> > Regards,
> >> > Jamie
> >> >
> >> >
> >> > "vt" wrote:
> >> >
> >> >> Does your maintenance plan include master databases, if so remove it
> >> >> from
> >> >> ur
> >> >> maintenance plan darabase list..
> >> >> vinu
> >> >>
> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> >> >> > Can you give me a hint on this... it appears to be in normal mode -
> >> >> > not
> >> >> > recovery mode.
> >> >> > --
> >> >> > Regards,
> >> >> > Jamie
> >> >> >
> >> >> >
> >> >> > "Tracy McKibben" wrote:
> >> >> >
> >> >> >> thejamie wrote:
> >> >> >> > That particular database is a production database. Why would it
> >> >> >> > be
> >> >> >> > in
> >> >> >> > simple
> >> >> >> > recovery mode?
> >> >> >>
> >> >> >> Only you can answer that question...
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Tracy McKibben
> >> >> >> MCDBA
> >> >> >> http://www.realsqlguy.com
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>|||Run this in query analyzer:
alter database dbname
set recovery Full
No reboot required
thejamie wrote:
> Thanks to all of you. This is a big load off my mind.
> --
> Regards,
> Jamie
>
> "vt" wrote:
> > I don't think server will ask you to reboot
> > go ahead
> >
> > vt
> >
> >
> >
> > "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> > > Yes. That's right. Will the server need anything more than a reboot to
> > > enter full recovery mode?
> > > --
> > > Regards,
> > > Jamie
> > >
> > >
> > > "vt" wrote:
> > >
> > >> With simple recovery mode you will not be able to do point in time
> > >> restore
> > >> read BOL (Book online) for more detail..
> > >>
> > >> vinu
> > >>
> > >>
> > >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> > >> > Thanks. I am in simple recovery mode. I would like to know I can
> > >> > run a
> > >> > point in time restore. Do I need to switch to FULL recovery mode for
> > >> > this?
> > >> > --
> > >> > Regards,
> > >> > Jamie
> > >> >
> > >> >
> > >> > "vt" wrote:
> > >> >
> > >> >> Does your maintenance plan include master databases, if so remove it
> > >> >> from
> > >> >> ur
> > >> >> maintenance plan darabase list..
> > >> >> vinu
> > >> >>
> > >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> > >> >> > Can you give me a hint on this... it appears to be in normal mode -
> > >> >> > not
> > >> >> > recovery mode.
> > >> >> > --
> > >> >> > Regards,
> > >> >> > Jamie
> > >> >> >
> > >> >> >
> > >> >> > "Tracy McKibben" wrote:
> > >> >> >
> > >> >> >> thejamie wrote:
> > >> >> >> > That particular database is a production database. Why would it
> > >> >> >> > be
> > >> >> >> > in
> > >> >> >> > simple
> > >> >> >> > recovery mode?
> > >> >> >>
> > >> >> >> Only you can answer that question...
> > >> >> >>
> > >> >> >>
> > >> >> >> --
> > >> >> >> Tracy McKibben
> > >> >> >> MCDBA
> > >> >> >> http://www.realsqlguy.com
> > >> >> >>
> > >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> > >>
> >
> >
> >|||"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
> Thanks to all of you. This is a big load off my mind.
Umm, not quite.
Make sure you do transaction log backups.
And keep in mind a disaster recovery plan is far more than simply "turning
on backups".
It's managing them among other things.
How many often will you take a full backup? How long will you keep it?
How often will you take transaction backups. How long will you keep them?
Etc.
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> I don't think server will ask you to reboot
>> go ahead
>> vt
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
>> > Yes. That's right. Will the server need anything more than a reboot
>> > to
>> > enter full recovery mode?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> With simple recovery mode you will not be able to do point in time
>> >> restore
>> >> read BOL (Book online) for more detail..
>> >>
>> >> vinu
>> >>
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> >> > Thanks. I am in simple recovery mode. I would like to know I can
>> >> > run a
>> >> > point in time restore. Do I need to switch to FULL recovery mode
>> >> > for
>> >> > this?
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "vt" wrote:
>> >> >
>> >> >> Does your maintenance plan include master databases, if so remove
>> >> >> it
>> >> >> from
>> >> >> ur
>> >> >> maintenance plan darabase list..
>> >> >> vinu
>> >> >>
>> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> >> > Can you give me a hint on this... it appears to be in normal
>> >> >> > mode -
>> >> >> > not
>> >> >> > recovery mode.
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Jamie
>> >> >> >
>> >> >> >
>> >> >> > "Tracy McKibben" wrote:
>> >> >> >
>> >> >> >> thejamie wrote:
>> >> >> >> > That particular database is a production database. Why would
>> >> >> >> > it
>> >> >> >> > be
>> >> >> >> > in
>> >> >> >> > simple
>> >> >> >> > recovery mode?
>> >> >> >>
>> >> >> >> Only you can answer that question...
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Tracy McKibben
>> >> >> >> MCDBA
>> >> >> >> http://www.realsqlguy.com
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>|||And what kind of testing will you do to make sure you can smoothly recover
from your backups when the need arises?
--
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:%23zodPZgAHHA.3836@.TK2MSFTNGP02.phx.gbl...
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
>> Thanks to all of you. This is a big load off my mind.
> Umm, not quite.
> Make sure you do transaction log backups.
> And keep in mind a disaster recovery plan is far more than simply "turning
> on backups".
> It's managing them among other things.
> How many often will you take a full backup? How long will you keep it?
> How often will you take transaction backups. How long will you keep them?
> Etc.
>
>> --
>> Regards,
>> Jamie
>>
>> "vt" wrote:
>> I don't think server will ask you to reboot
>> go ahead
>> vt
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
>> > Yes. That's right. Will the server need anything more than a reboot
>> > to
>> > enter full recovery mode?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> With simple recovery mode you will not be able to do point in time
>> >> restore
>> >> read BOL (Book online) for more detail..
>> >>
>> >> vinu
>> >>
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> >> > Thanks. I am in simple recovery mode. I would like to know I
>> >> > can
>> >> > run a
>> >> > point in time restore. Do I need to switch to FULL recovery mode
>> >> > for
>> >> > this?
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "vt" wrote:
>> >> >
>> >> >> Does your maintenance plan include master databases, if so remove
>> >> >> it
>> >> >> from
>> >> >> ur
>> >> >> maintenance plan darabase list..
>> >> >> vinu
>> >> >>
>> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> >> > Can you give me a hint on this... it appears to be in normal
>> >> >> > mode -
>> >> >> > not
>> >> >> > recovery mode.
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Jamie
>> >> >> >
>> >> >> >
>> >> >> > "Tracy McKibben" wrote:
>> >> >> >
>> >> >> >> thejamie wrote:
>> >> >> >> > That particular database is a production database. Why would
>> >> >> >> > it
>> >> >> >> > be
>> >> >> >> > in
>> >> >> >> > simple
>> >> >> >> > recovery mode?
>> >> >> >>
>> >> >> >> Only you can answer that question...
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Tracy McKibben
>> >> >> >> MCDBA
>> >> >> >> http://www.realsqlguy.com
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>|||We're running simulations on virtual servers. Thanks again everyone for your
help.
--
Regards,
Jamie
"Kalen Delaney" wrote:
> And what kind of testing will you do to make sure you can smoothly recover
> from your backups when the need arises?
> --
> HTH
> Kalen Delaney, SQL Server MVP
> http://sqlblog.com
>
> "Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
> news:%23zodPZgAHHA.3836@.TK2MSFTNGP02.phx.gbl...
> >
> > "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
> >> Thanks to all of you. This is a big load off my mind.
> >
> > Umm, not quite.
> >
> > Make sure you do transaction log backups.
> >
> > And keep in mind a disaster recovery plan is far more than simply "turning
> > on backups".
> >
> > It's managing them among other things.
> >
> > How many often will you take a full backup? How long will you keep it?
> >
> > How often will you take transaction backups. How long will you keep them?
> >
> > Etc.
> >
> >
> >> --
> >> Regards,
> >> Jamie
> >>
> >>
> >> "vt" wrote:
> >>
> >> I don't think server will ask you to reboot
> >> go ahead
> >>
> >> vt
> >>
> >>
> >>
> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> >> > Yes. That's right. Will the server need anything more than a reboot
> >> > to
> >> > enter full recovery mode?
> >> > --
> >> > Regards,
> >> > Jamie
> >> >
> >> >
> >> > "vt" wrote:
> >> >
> >> >> With simple recovery mode you will not be able to do point in time
> >> >> restore
> >> >> read BOL (Book online) for more detail..
> >> >>
> >> >> vinu
> >> >>
> >> >>
> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> >> >> > Thanks. I am in simple recovery mode. I would like to know I
> >> >> > can
> >> >> > run a
> >> >> > point in time restore. Do I need to switch to FULL recovery mode
> >> >> > for
> >> >> > this?
> >> >> > --
> >> >> > Regards,
> >> >> > Jamie
> >> >> >
> >> >> >
> >> >> > "vt" wrote:
> >> >> >
> >> >> >> Does your maintenance plan include master databases, if so remove
> >> >> >> it
> >> >> >> from
> >> >> >> ur
> >> >> >> maintenance plan darabase list..
> >> >> >> vinu
> >> >> >>
> >> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> >> >> >> > Can you give me a hint on this... it appears to be in normal
> >> >> >> > mode -
> >> >> >> > not
> >> >> >> > recovery mode.
> >> >> >> > --
> >> >> >> > Regards,
> >> >> >> > Jamie
> >> >> >> >
> >> >> >> >
> >> >> >> > "Tracy McKibben" wrote:
> >> >> >> >
> >> >> >> >> thejamie wrote:
> >> >> >> >> > That particular database is a production database. Why would
> >> >> >> >> > it
> >> >> >> >> > be
> >> >> >> >> > in
> >> >> >> >> > simple
> >> >> >> >> > recovery mode?
> >> >> >> >>
> >> >> >> >> Only you can answer that question...
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Tracy McKibben
> >> >> >> >> MCDBA
> >> >> >> >> http://www.realsqlguy.com
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
> >
> >
>
>|||"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:eEBNUqgAHHA.1220@.TK2MSFTNGP04.phx.gbl...
> And what kind of testing will you do to make sure you can smoothly recover
> from your backups when the need arises?
>
Oh yeah. Good point. :-)
(We do home rolled log-shipping of most of our databases, which is a real
good check that backups are working etc. ;-)
> --
> HTH
> Kalen Delaney, SQL Server MVP
> http://sqlblog.com
>
> "Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in
> message news:%23zodPZgAHHA.3836@.TK2MSFTNGP02.phx.gbl...
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
>> Thanks to all of you. This is a big load off my mind.
>> Umm, not quite.
>> Make sure you do transaction log backups.
>> And keep in mind a disaster recovery plan is far more than simply
>> "turning on backups".
>> It's managing them among other things.
>> How many often will you take a full backup? How long will you keep it?
>> How often will you take transaction backups. How long will you keep
>> them?
>> Etc.
>>
>> --
>> Regards,
>> Jamie
>>
>> "vt" wrote:
>> I don't think server will ask you to reboot
>> go ahead
>> vt
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
>> > Yes. That's right. Will the server need anything more than a reboot
>> > to
>> > enter full recovery mode?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> With simple recovery mode you will not be able to do point in time
>> >> restore
>> >> read BOL (Book online) for more detail..
>> >>
>> >> vinu
>> >>
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> >> > Thanks. I am in simple recovery mode. I would like to know I
>> >> > can
>> >> > run a
>> >> > point in time restore. Do I need to switch to FULL recovery mode
>> >> > for
>> >> > this?
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "vt" wrote:
>> >> >
>> >> >> Does your maintenance plan include master databases, if so remove
>> >> >> it
>> >> >> from
>> >> >> ur
>> >> >> maintenance plan darabase list..
>> >> >> vinu
>> >> >>
>> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> >> > Can you give me a hint on this... it appears to be in normal
>> >> >> > mode -
>> >> >> > not
>> >> >> > recovery mode.
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Jamie
>> >> >> >
>> >> >> >
>> >> >> > "Tracy McKibben" wrote:
>> >> >> >
>> >> >> >> thejamie wrote:
>> >> >> >> > That particular database is a production database. Why
>> >> >> >> > would it
>> >> >> >> > be
>> >> >> >> > in
>> >> >> >> > simple
>> >> >> >> > recovery mode?
>> >> >> >>
>> >> >> >> Only you can answer that question...
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Tracy McKibben
>> >> >> >> MCDBA
>> >> >> >> http://www.realsqlguy.com
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>
We are having production problems - time outs. Does the optimization plan
for DB Maintenence drop bad indexes - simply put, what is my best way to
handle back indexes on a production server?
--
Regards,
JamieError is:
Backup can not be performed on this database. This sub task is ignored
--
Regards,
Jamie
"thejamie" wrote:
> I see errors in my DB Maint log that indicates indexes are not being rebuilt.
> We are having production problems - time outs. Does the optimization plan
> for DB Maintenence drop bad indexes - simply put, what is my best way to
> handle back indexes on a production server?
> --
> Regards,
> Jamie|||thejamie wrote:
> Error is:
> Backup can not be performed on this database. This sub task is ignored
That has nothing to do with indexes... This error is telling you that
you are attempting to do a transaction log backup against a database
that is in Simple recovery mode.
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||That particular database is a production database. Why would it be in simple
recovery mode?
--
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> > Error is:
> > Backup can not be performed on this database. This sub task is ignored
> That has nothing to do with indexes... This error is telling you that
> you are attempting to do a transaction log backup against a database
> that is in Simple recovery mode.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||thejamie wrote:
> That particular database is a production database. Why would it be in simple
> recovery mode?
Only you can answer that question...
Tracy McKibben
MCDBA
http://www.realsqlguy.com|||Can you give me a hint on this... it appears to be in normal mode - not
recovery mode.
--
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> > That particular database is a production database. Why would it be in simple
> > recovery mode?
> Only you can answer that question...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>|||Open the database property window, select the option tab and check what
recovery mode your database on
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
>> thejamie wrote:
>> > That particular database is a production database. Why would it be in
>> > simple
>> > recovery mode?
>> Only you can answer that question...
>>
>> --
>> Tracy McKibben
>> MCDBA
>> http://www.realsqlguy.com|||Does your maintenance plan include master databases, if so remove it from ur
maintenance plan darabase list..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
>> thejamie wrote:
>> > That particular database is a production database. Why would it be in
>> > simple
>> > recovery mode?
>> Only you can answer that question...
>>
>> --
>> Tracy McKibben
>> MCDBA
>> http://www.realsqlguy.com|||Thanks. I am in simple recovery mode. I would like to know I can run a
point in time restore. Do I need to switch to FULL recovery mode for this?
--
Regards,
Jamie
"vt" wrote:
> Does your maintenance plan include master databases, if so remove it from ur
> maintenance plan darabase list..
> vinu
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> > Can you give me a hint on this... it appears to be in normal mode - not
> > recovery mode.
> > --
> > Regards,
> > Jamie
> >
> >
> > "Tracy McKibben" wrote:
> >
> >> thejamie wrote:
> >> > That particular database is a production database. Why would it be in
> >> > simple
> >> > recovery mode?
> >>
> >> Only you can answer that question...
> >>
> >>
> >> --
> >> Tracy McKibben
> >> MCDBA
> >> http://www.realsqlguy.com
> >>
>
>|||With simple recovery mode you will not be able to do point in time restore
read BOL (Book online) for more detail..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> Thanks. I am in simple recovery mode. I would like to know I can run a
> point in time restore. Do I need to switch to FULL recovery mode for
> this?
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> Does your maintenance plan include master databases, if so remove it from
>> ur
>> maintenance plan darabase list..
>> vinu
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> > Can you give me a hint on this... it appears to be in normal mode - not
>> > recovery mode.
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "Tracy McKibben" wrote:
>> >
>> >> thejamie wrote:
>> >> > That particular database is a production database. Why would it be
>> >> > in
>> >> > simple
>> >> > recovery mode?
>> >>
>> >> Only you can answer that question...
>> >>
>> >>
>> >> --
>> >> Tracy McKibben
>> >> MCDBA
>> >> http://www.realsqlguy.com
>> >>
>>|||Yes. That's right. Will the server need anything more than a reboot to
enter full recovery mode?
--
Regards,
Jamie
"vt" wrote:
> With simple recovery mode you will not be able to do point in time restore
> read BOL (Book online) for more detail..
> vinu
>
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> > Thanks. I am in simple recovery mode. I would like to know I can run a
> > point in time restore. Do I need to switch to FULL recovery mode for
> > this?
> > --
> > Regards,
> > Jamie
> >
> >
> > "vt" wrote:
> >
> >> Does your maintenance plan include master databases, if so remove it from
> >> ur
> >> maintenance plan darabase list..
> >> vinu
> >>
> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> >> > Can you give me a hint on this... it appears to be in normal mode - not
> >> > recovery mode.
> >> > --
> >> > Regards,
> >> > Jamie
> >> >
> >> >
> >> > "Tracy McKibben" wrote:
> >> >
> >> >> thejamie wrote:
> >> >> > That particular database is a production database. Why would it be
> >> >> > in
> >> >> > simple
> >> >> > recovery mode?
> >> >>
> >> >> Only you can answer that question...
> >> >>
> >> >>
> >> >> --
> >> >> Tracy McKibben
> >> >> MCDBA
> >> >> http://www.realsqlguy.com
> >> >>
> >>
> >>
> >>
>
>|||Hi Jamie
You don't even need to reboot. Just change to FULL, then make a full db
backup.
From that point on, you will be able to make log backups, and use them to
restore to a specific point in time, when necessary.
Please read the documentation on log backups and recovery models.
--
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> Yes. That's right. Will the server need anything more than a reboot to
> enter full recovery mode?
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> With simple recovery mode you will not be able to do point in time
>> restore
>> read BOL (Book online) for more detail..
>> vinu
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> > Thanks. I am in simple recovery mode. I would like to know I can
>> > run a
>> > point in time restore. Do I need to switch to FULL recovery mode for
>> > this?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> Does your maintenance plan include master databases, if so remove it
>> >> from
>> >> ur
>> >> maintenance plan darabase list..
>> >> vinu
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> > Can you give me a hint on this... it appears to be in normal mode -
>> >> > not
>> >> > recovery mode.
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "Tracy McKibben" wrote:
>> >> >
>> >> >> thejamie wrote:
>> >> >> > That particular database is a production database. Why would it
>> >> >> > be
>> >> >> > in
>> >> >> > simple
>> >> >> > recovery mode?
>> >> >>
>> >> >> Only you can answer that question...
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Tracy McKibben
>> >> >> MCDBA
>> >> >> http://www.realsqlguy.com
>> >> >>
>> >>
>> >>
>> >>
>>|||I don't think server will ask you to reboot
go ahead
vt
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> Yes. That's right. Will the server need anything more than a reboot to
> enter full recovery mode?
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> With simple recovery mode you will not be able to do point in time
>> restore
>> read BOL (Book online) for more detail..
>> vinu
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> > Thanks. I am in simple recovery mode. I would like to know I can
>> > run a
>> > point in time restore. Do I need to switch to FULL recovery mode for
>> > this?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> Does your maintenance plan include master databases, if so remove it
>> >> from
>> >> ur
>> >> maintenance plan darabase list..
>> >> vinu
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> > Can you give me a hint on this... it appears to be in normal mode -
>> >> > not
>> >> > recovery mode.
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "Tracy McKibben" wrote:
>> >> >
>> >> >> thejamie wrote:
>> >> >> > That particular database is a production database. Why would it
>> >> >> > be
>> >> >> > in
>> >> >> > simple
>> >> >> > recovery mode?
>> >> >>
>> >> >> Only you can answer that question...
>> >> >>
>> >> >>
>> >> >> --
>> >> >> Tracy McKibben
>> >> >> MCDBA
>> >> >> http://www.realsqlguy.com
>> >> >>
>> >>
>> >>
>> >>
>>|||Thanks to all of you. This is a big load off my mind.
--
Regards,
Jamie
"vt" wrote:
> I don't think server will ask you to reboot
> go ahead
> vt
>
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> > Yes. That's right. Will the server need anything more than a reboot to
> > enter full recovery mode?
> > --
> > Regards,
> > Jamie
> >
> >
> > "vt" wrote:
> >
> >> With simple recovery mode you will not be able to do point in time
> >> restore
> >> read BOL (Book online) for more detail..
> >>
> >> vinu
> >>
> >>
> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> >> > Thanks. I am in simple recovery mode. I would like to know I can
> >> > run a
> >> > point in time restore. Do I need to switch to FULL recovery mode for
> >> > this?
> >> > --
> >> > Regards,
> >> > Jamie
> >> >
> >> >
> >> > "vt" wrote:
> >> >
> >> >> Does your maintenance plan include master databases, if so remove it
> >> >> from
> >> >> ur
> >> >> maintenance plan darabase list..
> >> >> vinu
> >> >>
> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> >> >> > Can you give me a hint on this... it appears to be in normal mode -
> >> >> > not
> >> >> > recovery mode.
> >> >> > --
> >> >> > Regards,
> >> >> > Jamie
> >> >> >
> >> >> >
> >> >> > "Tracy McKibben" wrote:
> >> >> >
> >> >> >> thejamie wrote:
> >> >> >> > That particular database is a production database. Why would it
> >> >> >> > be
> >> >> >> > in
> >> >> >> > simple
> >> >> >> > recovery mode?
> >> >> >>
> >> >> >> Only you can answer that question...
> >> >> >>
> >> >> >>
> >> >> >> --
> >> >> >> Tracy McKibben
> >> >> >> MCDBA
> >> >> >> http://www.realsqlguy.com
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
>
>|||Run this in query analyzer:
alter database dbname
set recovery Full
No reboot required
thejamie wrote:
> Thanks to all of you. This is a big load off my mind.
> --
> Regards,
> Jamie
>
> "vt" wrote:
> > I don't think server will ask you to reboot
> > go ahead
> >
> > vt
> >
> >
> >
> > "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> > > Yes. That's right. Will the server need anything more than a reboot to
> > > enter full recovery mode?
> > > --
> > > Regards,
> > > Jamie
> > >
> > >
> > > "vt" wrote:
> > >
> > >> With simple recovery mode you will not be able to do point in time
> > >> restore
> > >> read BOL (Book online) for more detail..
> > >>
> > >> vinu
> > >>
> > >>
> > >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> > >> > Thanks. I am in simple recovery mode. I would like to know I can
> > >> > run a
> > >> > point in time restore. Do I need to switch to FULL recovery mode for
> > >> > this?
> > >> > --
> > >> > Regards,
> > >> > Jamie
> > >> >
> > >> >
> > >> > "vt" wrote:
> > >> >
> > >> >> Does your maintenance plan include master databases, if so remove it
> > >> >> from
> > >> >> ur
> > >> >> maintenance plan darabase list..
> > >> >> vinu
> > >> >>
> > >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> > >> >> > Can you give me a hint on this... it appears to be in normal mode -
> > >> >> > not
> > >> >> > recovery mode.
> > >> >> > --
> > >> >> > Regards,
> > >> >> > Jamie
> > >> >> >
> > >> >> >
> > >> >> > "Tracy McKibben" wrote:
> > >> >> >
> > >> >> >> thejamie wrote:
> > >> >> >> > That particular database is a production database. Why would it
> > >> >> >> > be
> > >> >> >> > in
> > >> >> >> > simple
> > >> >> >> > recovery mode?
> > >> >> >>
> > >> >> >> Only you can answer that question...
> > >> >> >>
> > >> >> >>
> > >> >> >> --
> > >> >> >> Tracy McKibben
> > >> >> >> MCDBA
> > >> >> >> http://www.realsqlguy.com
> > >> >> >>
> > >> >>
> > >> >>
> > >> >>
> > >>
> > >>
> > >>
> >
> >
> >|||"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
> Thanks to all of you. This is a big load off my mind.
Umm, not quite.
Make sure you do transaction log backups.
And keep in mind a disaster recovery plan is far more than simply "turning
on backups".
It's managing them among other things.
How many often will you take a full backup? How long will you keep it?
How often will you take transaction backups. How long will you keep them?
Etc.
> --
> Regards,
> Jamie
>
> "vt" wrote:
>> I don't think server will ask you to reboot
>> go ahead
>> vt
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
>> > Yes. That's right. Will the server need anything more than a reboot
>> > to
>> > enter full recovery mode?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> With simple recovery mode you will not be able to do point in time
>> >> restore
>> >> read BOL (Book online) for more detail..
>> >>
>> >> vinu
>> >>
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> >> > Thanks. I am in simple recovery mode. I would like to know I can
>> >> > run a
>> >> > point in time restore. Do I need to switch to FULL recovery mode
>> >> > for
>> >> > this?
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "vt" wrote:
>> >> >
>> >> >> Does your maintenance plan include master databases, if so remove
>> >> >> it
>> >> >> from
>> >> >> ur
>> >> >> maintenance plan darabase list..
>> >> >> vinu
>> >> >>
>> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> >> > Can you give me a hint on this... it appears to be in normal
>> >> >> > mode -
>> >> >> > not
>> >> >> > recovery mode.
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Jamie
>> >> >> >
>> >> >> >
>> >> >> > "Tracy McKibben" wrote:
>> >> >> >
>> >> >> >> thejamie wrote:
>> >> >> >> > That particular database is a production database. Why would
>> >> >> >> > it
>> >> >> >> > be
>> >> >> >> > in
>> >> >> >> > simple
>> >> >> >> > recovery mode?
>> >> >> >>
>> >> >> >> Only you can answer that question...
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Tracy McKibben
>> >> >> >> MCDBA
>> >> >> >> http://www.realsqlguy.com
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>|||And what kind of testing will you do to make sure you can smoothly recover
from your backups when the need arises?
--
HTH
Kalen Delaney, SQL Server MVP
http://sqlblog.com
"Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
news:%23zodPZgAHHA.3836@.TK2MSFTNGP02.phx.gbl...
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
>> Thanks to all of you. This is a big load off my mind.
> Umm, not quite.
> Make sure you do transaction log backups.
> And keep in mind a disaster recovery plan is far more than simply "turning
> on backups".
> It's managing them among other things.
> How many often will you take a full backup? How long will you keep it?
> How often will you take transaction backups. How long will you keep them?
> Etc.
>
>> --
>> Regards,
>> Jamie
>>
>> "vt" wrote:
>> I don't think server will ask you to reboot
>> go ahead
>> vt
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
>> > Yes. That's right. Will the server need anything more than a reboot
>> > to
>> > enter full recovery mode?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> With simple recovery mode you will not be able to do point in time
>> >> restore
>> >> read BOL (Book online) for more detail..
>> >>
>> >> vinu
>> >>
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> >> > Thanks. I am in simple recovery mode. I would like to know I
>> >> > can
>> >> > run a
>> >> > point in time restore. Do I need to switch to FULL recovery mode
>> >> > for
>> >> > this?
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "vt" wrote:
>> >> >
>> >> >> Does your maintenance plan include master databases, if so remove
>> >> >> it
>> >> >> from
>> >> >> ur
>> >> >> maintenance plan darabase list..
>> >> >> vinu
>> >> >>
>> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> >> > Can you give me a hint on this... it appears to be in normal
>> >> >> > mode -
>> >> >> > not
>> >> >> > recovery mode.
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Jamie
>> >> >> >
>> >> >> >
>> >> >> > "Tracy McKibben" wrote:
>> >> >> >
>> >> >> >> thejamie wrote:
>> >> >> >> > That particular database is a production database. Why would
>> >> >> >> > it
>> >> >> >> > be
>> >> >> >> > in
>> >> >> >> > simple
>> >> >> >> > recovery mode?
>> >> >> >>
>> >> >> >> Only you can answer that question...
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Tracy McKibben
>> >> >> >> MCDBA
>> >> >> >> http://www.realsqlguy.com
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>|||We're running simulations on virtual servers. Thanks again everyone for your
help.
--
Regards,
Jamie
"Kalen Delaney" wrote:
> And what kind of testing will you do to make sure you can smoothly recover
> from your backups when the need arises?
> --
> HTH
> Kalen Delaney, SQL Server MVP
> http://sqlblog.com
>
> "Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in message
> news:%23zodPZgAHHA.3836@.TK2MSFTNGP02.phx.gbl...
> >
> > "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> > news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
> >> Thanks to all of you. This is a big load off my mind.
> >
> > Umm, not quite.
> >
> > Make sure you do transaction log backups.
> >
> > And keep in mind a disaster recovery plan is far more than simply "turning
> > on backups".
> >
> > It's managing them among other things.
> >
> > How many often will you take a full backup? How long will you keep it?
> >
> > How often will you take transaction backups. How long will you keep them?
> >
> > Etc.
> >
> >
> >> --
> >> Regards,
> >> Jamie
> >>
> >>
> >> "vt" wrote:
> >>
> >> I don't think server will ask you to reboot
> >> go ahead
> >>
> >> vt
> >>
> >>
> >>
> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
> >> > Yes. That's right. Will the server need anything more than a reboot
> >> > to
> >> > enter full recovery mode?
> >> > --
> >> > Regards,
> >> > Jamie
> >> >
> >> >
> >> > "vt" wrote:
> >> >
> >> >> With simple recovery mode you will not be able to do point in time
> >> >> restore
> >> >> read BOL (Book online) for more detail..
> >> >>
> >> >> vinu
> >> >>
> >> >>
> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
> >> >> > Thanks. I am in simple recovery mode. I would like to know I
> >> >> > can
> >> >> > run a
> >> >> > point in time restore. Do I need to switch to FULL recovery mode
> >> >> > for
> >> >> > this?
> >> >> > --
> >> >> > Regards,
> >> >> > Jamie
> >> >> >
> >> >> >
> >> >> > "vt" wrote:
> >> >> >
> >> >> >> Does your maintenance plan include master databases, if so remove
> >> >> >> it
> >> >> >> from
> >> >> >> ur
> >> >> >> maintenance plan darabase list..
> >> >> >> vinu
> >> >> >>
> >> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> >> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
> >> >> >> > Can you give me a hint on this... it appears to be in normal
> >> >> >> > mode -
> >> >> >> > not
> >> >> >> > recovery mode.
> >> >> >> > --
> >> >> >> > Regards,
> >> >> >> > Jamie
> >> >> >> >
> >> >> >> >
> >> >> >> > "Tracy McKibben" wrote:
> >> >> >> >
> >> >> >> >> thejamie wrote:
> >> >> >> >> > That particular database is a production database. Why would
> >> >> >> >> > it
> >> >> >> >> > be
> >> >> >> >> > in
> >> >> >> >> > simple
> >> >> >> >> > recovery mode?
> >> >> >> >>
> >> >> >> >> Only you can answer that question...
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> --
> >> >> >> >> Tracy McKibben
> >> >> >> >> MCDBA
> >> >> >> >> http://www.realsqlguy.com
> >> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >> >>
> >>
> >>
> >>
> >
> >
>
>|||"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:eEBNUqgAHHA.1220@.TK2MSFTNGP04.phx.gbl...
> And what kind of testing will you do to make sure you can smoothly recover
> from your backups when the need arises?
>
Oh yeah. Good point. :-)
(We do home rolled log-shipping of most of our databases, which is a real
good check that backups are working etc. ;-)
> --
> HTH
> Kalen Delaney, SQL Server MVP
> http://sqlblog.com
>
> "Greg D. Moore (Strider)" <mooregr_deleteth1s@.greenms.com> wrote in
> message news:%23zodPZgAHHA.3836@.TK2MSFTNGP02.phx.gbl...
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:D8A1EEBD-95A0-4DB4-B40A-AD3AD0EA4E22@.microsoft.com...
>> Thanks to all of you. This is a big load off my mind.
>> Umm, not quite.
>> Make sure you do transaction log backups.
>> And keep in mind a disaster recovery plan is far more than simply
>> "turning on backups".
>> It's managing them among other things.
>> How many often will you take a full backup? How long will you keep it?
>> How often will you take transaction backups. How long will you keep
>> them?
>> Etc.
>>
>> --
>> Regards,
>> Jamie
>>
>> "vt" wrote:
>> I don't think server will ask you to reboot
>> go ahead
>> vt
>>
>> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> news:7A6C958E-1DBD-4E41-8361-75FA5EE7996E@.microsoft.com...
>> > Yes. That's right. Will the server need anything more than a reboot
>> > to
>> > enter full recovery mode?
>> > --
>> > Regards,
>> > Jamie
>> >
>> >
>> > "vt" wrote:
>> >
>> >> With simple recovery mode you will not be able to do point in time
>> >> restore
>> >> read BOL (Book online) for more detail..
>> >>
>> >> vinu
>> >>
>> >>
>> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...
>> >> > Thanks. I am in simple recovery mode. I would like to know I
>> >> > can
>> >> > run a
>> >> > point in time restore. Do I need to switch to FULL recovery mode
>> >> > for
>> >> > this?
>> >> > --
>> >> > Regards,
>> >> > Jamie
>> >> >
>> >> >
>> >> > "vt" wrote:
>> >> >
>> >> >> Does your maintenance plan include master databases, if so remove
>> >> >> it
>> >> >> from
>> >> >> ur
>> >> >> maintenance plan darabase list..
>> >> >> vinu
>> >> >>
>> >> >> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
>> >> >> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>> >> >> > Can you give me a hint on this... it appears to be in normal
>> >> >> > mode -
>> >> >> > not
>> >> >> > recovery mode.
>> >> >> > --
>> >> >> > Regards,
>> >> >> > Jamie
>> >> >> >
>> >> >> >
>> >> >> > "Tracy McKibben" wrote:
>> >> >> >
>> >> >> >> thejamie wrote:
>> >> >> >> > That particular database is a production database. Why
>> >> >> >> > would it
>> >> >> >> > be
>> >> >> >> > in
>> >> >> >> > simple
>> >> >> >> > recovery mode?
>> >> >> >>
>> >> >> >> Only you can answer that question...
>> >> >> >>
>> >> >> >>
>> >> >> >> --
>> >> >> >> Tracy McKibben
>> >> >> >> MCDBA
>> >> >> >> http://www.realsqlguy.com
>> >> >> >>
>> >> >>
>> >> >>
>> >> >>
>> >>
>> >>
>> >>
>>
>>
>
Indexes not rebuilding on SQL 2K DB MAINT PLAN
I see errors in my DB Maint log that indicates indexes are not being rebuilt.
We are having production problems - time outs. Does the optimization plan
for DB Maintenence drop bad indexes - simply put, what is my best way to
handle back indexes on a production server?
Regards,
Jamie
Error is:
Backup can not be performed on this database. This sub task is ignored
Regards,
Jamie
"thejamie" wrote:
> I see errors in my DB Maint log that indicates indexes are not being rebuilt.
> We are having production problems - time outs. Does the optimization plan
> for DB Maintenence drop bad indexes - simply put, what is my best way to
> handle back indexes on a production server?
> --
> Regards,
> Jamie
|||thejamie wrote:
> Error is:
> Backup can not be performed on this database. This sub task is ignored
That has nothing to do with indexes... This error is telling you that
you are attempting to do a transaction log backup against a database
that is in Simple recovery mode.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||That particular database is a production database. Why would it be in simple
recovery mode?
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> That has nothing to do with indexes... This error is telling you that
> you are attempting to do a transaction log backup against a database
> that is in Simple recovery mode.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>
|||thejamie wrote:
> That particular database is a production database. Why would it be in simple
> recovery mode?
Only you can answer that question...
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Can you give me a hint on this... it appears to be in normal mode - not
recovery mode.
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> Only you can answer that question...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>
|||Open the database property window, select the option tab and check what
recovery mode your database on
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...[vbcol=seagreen]
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
|||Does your maintenance plan include master databases, if so remove it from ur
maintenance plan darabase list..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...[vbcol=seagreen]
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
|||Thanks. I am in simple recovery mode. I would like to know I can run a
point in time restore. Do I need to switch to FULL recovery mode for this?
Regards,
Jamie
"vt" wrote:
> Does your maintenance plan include master databases, if so remove it from ur
> maintenance plan darabase list..
> vinu
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>
>
|||With simple recovery mode you will not be able to do point in time restore
read BOL (Book online) for more detail..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...[vbcol=seagreen]
> Thanks. I am in simple recovery mode. I would like to know I can run a
> point in time restore. Do I need to switch to FULL recovery mode for
> this?
> --
> Regards,
> Jamie
>
> "vt" wrote:
We are having production problems - time outs. Does the optimization plan
for DB Maintenence drop bad indexes - simply put, what is my best way to
handle back indexes on a production server?
Regards,
Jamie
Error is:
Backup can not be performed on this database. This sub task is ignored
Regards,
Jamie
"thejamie" wrote:
> I see errors in my DB Maint log that indicates indexes are not being rebuilt.
> We are having production problems - time outs. Does the optimization plan
> for DB Maintenence drop bad indexes - simply put, what is my best way to
> handle back indexes on a production server?
> --
> Regards,
> Jamie
|||thejamie wrote:
> Error is:
> Backup can not be performed on this database. This sub task is ignored
That has nothing to do with indexes... This error is telling you that
you are attempting to do a transaction log backup against a database
that is in Simple recovery mode.
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||That particular database is a production database. Why would it be in simple
recovery mode?
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> That has nothing to do with indexes... This error is telling you that
> you are attempting to do a transaction log backup against a database
> that is in Simple recovery mode.
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>
|||thejamie wrote:
> That particular database is a production database. Why would it be in simple
> recovery mode?
Only you can answer that question...
Tracy McKibben
MCDBA
http://www.realsqlguy.com
|||Can you give me a hint on this... it appears to be in normal mode - not
recovery mode.
Regards,
Jamie
"Tracy McKibben" wrote:
> thejamie wrote:
> Only you can answer that question...
>
> --
> Tracy McKibben
> MCDBA
> http://www.realsqlguy.com
>
|||Open the database property window, select the option tab and check what
recovery mode your database on
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...[vbcol=seagreen]
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
|||Does your maintenance plan include master databases, if so remove it from ur
maintenance plan darabase list..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...[vbcol=seagreen]
> Can you give me a hint on this... it appears to be in normal mode - not
> recovery mode.
> --
> Regards,
> Jamie
>
> "Tracy McKibben" wrote:
|||Thanks. I am in simple recovery mode. I would like to know I can run a
point in time restore. Do I need to switch to FULL recovery mode for this?
Regards,
Jamie
"vt" wrote:
> Does your maintenance plan include master databases, if so remove it from ur
> maintenance plan darabase list..
> vinu
> "thejamie" <thejamie@.discussions.microsoft.com> wrote in message
> news:2D4155FC-D55C-4C9C-9630-1327B0E66D0B@.microsoft.com...
>
>
|||With simple recovery mode you will not be able to do point in time restore
read BOL (Book online) for more detail..
vinu
"thejamie" <thejamie@.discussions.microsoft.com> wrote in message
news:F1B75A04-D4AF-4F82-BBBE-681891483C4B@.microsoft.com...[vbcol=seagreen]
> Thanks. I am in simple recovery mode. I would like to know I can run a
> point in time restore. Do I need to switch to FULL recovery mode for
> this?
> --
> Regards,
> Jamie
>
> "vt" wrote:
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)