DBfile usage: despite

Showing posts with label despite. Show all posts

Tuesday, March 27, 2012

dbcc shrinkdatabase error

Hi ,
i was trying to shrink a database but i got the following error :
it's something like " logical file is in use" despite me logging in as a
single user
the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
i have also used the EM's shrink database , though it says it completed
successfully but it did not shrink the database
kindly advise
tks & rdgsHi
What is the Error Number and Severity?
You might be getting an informational message to tell you that the DB can't
be shunk any smaller than it already is.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"maxzsim" wrote:
> Hi ,
> i was trying to shrink a database but i got the following error :
> it's something like " logical file is in use" despite me logging in as a
> single user
> the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
> i have also used the EM's shrink database , though it says it completed
> successfully but it did not shrink the database
> kindly advise
> tks & rdgs|||Hi,
Post the exact error.
I feel that Probably there will be some active transactions. Execute DBCC
OPENTRAN('DBNAME') to identify if there is any open active trans.
If yes, wait that to complete. After that you could execute a backup LOG to
clear the transaction log and then execute DBCC SHRINKFILE to
shrink MDF and LDF seperately.
Thanks
Hari
SQL Server MVP
"maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
> Hi ,
> i was trying to shrink a database but i got the following error :
> it's something like " logical file is in use" despite me logging in as a
> single user
> the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
> i have also used the EM's shrink database , though it says it completed
> successfully but it did not shrink the database
> kindly advise
> tks & rdgs|||Hi ,
before doing the shrink database , have already did a txn log bakup and it
says 4GB is free, though the log file is still occupying 5 GB
so thought of shrinking the database/log file and return the free space back
to OS
tks & rdgs
"Hari Prasad" wrote:
> Hi,
> Post the exact error.
> I feel that Probably there will be some active transactions. Execute DBCC
> OPENTRAN('DBNAME') to identify if there is any open active trans.
> If yes, wait that to complete. After that you could execute a backup LOG to
> clear the transaction log and then execute DBCC SHRINKFILE to
> shrink MDF and LDF seperately.
> Thanks
> Hari
> SQL Server MVP
> "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
> news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
> > Hi ,
> >
> > i was trying to shrink a database but i got the following error :
> > it's something like " logical file is in use" despite me logging in as a
> > single user
> >
> > the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
> >
> > i have also used the EM's shrink database , though it says it completed
> > successfully but it did not shrink the database
> >
> > kindly advise
> > tks & rdgs
>
>|||Hi ,
I have done a txn log backup file earlier and it says that 4GB is free
tks & rdgs
"Mike Epprecht (SQL MVP)" wrote:
> Hi
> What is the Error Number and Severity?
> You might be getting an informational message to tell you that the DB can't
> be shunk any smaller than it already is.
> Regards
> --
> Mike Epprecht, Microsoft SQL Server MVP
> Zurich, Switzerland
> MVP Program: http://www.microsoft.com/mvp
> Blog: http://www.msmvps.com/epprecht/
>
> "maxzsim" wrote:
> > Hi ,
> >
> > i was trying to shrink a database but i got the following error :
> > it's something like " logical file is in use" despite me logging in as a
> > single user
> >
> > the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
> >
> > i have also used the EM's shrink database , though it says it completed
> > successfully but it did not shrink the database
> >
> > kindly advise
> > tks & rdgs|||Hi
It all depends on where the "Virtual Log"/"Active Portion of the Log" is in
relation to the end of the log file.
The Active Portion may be close to the end of the file at the moment, so the
log can not be shrunk. Once the Active Portion is at the beginning of the log
file, then the log can be truncated to where it is.
Look at "virtual log files" in BOL.
--
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"maxzsim" wrote:
> Hi ,
> before doing the shrink database , have already did a txn log bakup and it
> says 4GB is free, though the log file is still occupying 5 GB
> so thought of shrinking the database/log file and return the free space back
> to OS
> tks & rdgs
> "Hari Prasad" wrote:
> > Hi,
> >
> > Post the exact error.
> >
> > I feel that Probably there will be some active transactions. Execute DBCC
> > OPENTRAN('DBNAME') to identify if there is any open active trans.
> > If yes, wait that to complete. After that you could execute a backup LOG to
> > clear the transaction log and then execute DBCC SHRINKFILE to
> > shrink MDF and LDF seperately.
> >
> > Thanks
> > Hari
> > SQL Server MVP
> >
> > "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
> > news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
> > > Hi ,
> > >
> > > i was trying to shrink a database but i got the following error :
> > > it's something like " logical file is in use" despite me logging in as a
> > > single user
> > >
> > > the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
> > >
> > > i have also used the EM's shrink database , though it says it completed
> > > successfully but it did not shrink the database
> > >
> > > kindly advise
> > > tks & rdgs
> >
> >
> >|||Are you trying to shrink the db file or the log file? Sounds like the log
file. You should use DBCC SHRINKFILE not database as it allows you to
choose the specific file you want to shrink and how much.
--
Andrew J. Kelly SQL MVP
"maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
> Hi ,
> i was trying to shrink a database but i got the following error :
> it's something like " logical file is in use" despite me logging in as a
> single user
> the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
> i have also used the EM's shrink database , though it says it completed
> successfully but it did not shrink the database
> kindly advise
> tks & rdgs|||Hi Andrew ,
i was trying to shrink the log file but it couldn't as per the error below
and i have also tried to shrink the database as well , hoping it'll shrink
the log file
tks & rdgs
"Andrew J. Kelly" wrote:
> Are you trying to shrink the db file or the log file? Sounds like the log
> file. You should use DBCC SHRINKFILE not database as it allows you to
> choose the specific file you want to shrink and how much.
> --
> Andrew J. Kelly SQL MVP
>
> "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
> news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
> > Hi ,
> >
> > i was trying to shrink a database but i got the following error :
> > it's something like " logical file is in use" despite me logging in as a
> > single user
> >
> > the statement i used : DBCC Shrinkdatabase ('dbname', 1 , truncate_only)
> >
> > i have also used the EM's shrink database , though it says it completed
> > successfully but it did not shrink the database
> >
> > kindly advise
> > tks & rdgs
>
>|||Did you actually try DBCC SHRINKFILE? If not you should. You don't need to
be in single user mode to run this.
--
Andrew J. Kelly SQL MVP
"maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
news:A84212A5-E2B0-4CF4-9F03-D4B84FCC4E59@.microsoft.com...
> Hi Andrew ,
> i was trying to shrink the log file but it couldn't as per the error
> below
> and i have also tried to shrink the database as well , hoping it'll shrink
> the log file
> tks & rdgs
> "Andrew J. Kelly" wrote:
>> Are you trying to shrink the db file or the log file? Sounds like the
>> log
>> file. You should use DBCC SHRINKFILE not database as it allows you to
>> choose the specific file you want to shrink and how much.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
>> news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
>> > Hi ,
>> >
>> > i was trying to shrink a database but i got the following error :
>> > it's something like " logical file is in use" despite me logging in as
>> > a
>> > single user
>> >
>> > the statement i used : DBCC Shrinkdatabase ('dbname', 1 ,
>> > truncate_only)
>> >
>> > i have also used the EM's shrink database , though it says it completed
>> > successfully but it did not shrink the database
>> >
>> > kindly advise
>> > tks & rdgs
>>|||Hi Andrew ,
i did tried with the DBCC shrink file statement but got the "logical log in
use" error as per the DBCC Shrinkdatabase. however, when i changed the mode
to "Simple" recovery mode , i could somehow shrink the db
tks & rdgs
"Andrew J. Kelly" wrote:
> Did you actually try DBCC SHRINKFILE? If not you should. You don't need to
> be in single user mode to run this.
> --
> Andrew J. Kelly SQL MVP
>
> "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
> news:A84212A5-E2B0-4CF4-9F03-D4B84FCC4E59@.microsoft.com...
> > Hi Andrew ,
> >
> > i was trying to shrink the log file but it couldn't as per the error
> > below
> > and i have also tried to shrink the database as well , hoping it'll shrink
> > the log file
> >
> > tks & rdgs
> >
> > "Andrew J. Kelly" wrote:
> >
> >> Are you trying to shrink the db file or the log file? Sounds like the
> >> log
> >> file. You should use DBCC SHRINKFILE not database as it allows you to
> >> choose the specific file you want to shrink and how much.
> >>
> >> --
> >> Andrew J. Kelly SQL MVP
> >>
> >>
> >> "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
> >> news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
> >> > Hi ,
> >> >
> >> > i was trying to shrink a database but i got the following error :
> >> > it's something like " logical file is in use" despite me logging in as
> >> > a
> >> > single user
> >> >
> >> > the statement i used : DBCC Shrinkdatabase ('dbname', 1 ,
> >> > truncate_only)
> >> >
> >> > i have also used the EM's shrink database , though it says it completed
> >> > successfully but it did not shrink the database
> >> >
> >> > kindly advise
> >> > tks & rdgs
> >>
> >>
> >>
>
>|||This is because the recovery mode you were in was preventing the log being
truncated until you'd backed it up. Switching to simple mode removes that
restriction. See BOL for more info ('Shrinking the Transaction Log' is a
good place to start)
Regards
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
news:65ADA556-3489-4620-844E-CC0DCB0BDF3A@.microsoft.com...
> Hi Andrew ,
> i did tried with the DBCC shrink file statement but got the "logical log
> in
> use" error as per the DBCC Shrinkdatabase. however, when i changed the
> mode
> to "Simple" recovery mode , i could somehow shrink the db
> tks & rdgs
> "Andrew J. Kelly" wrote:
>> Did you actually try DBCC SHRINKFILE? If not you should. You don't need
>> to
>> be in single user mode to run this.
>> --
>> Andrew J. Kelly SQL MVP
>>
>> "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
>> news:A84212A5-E2B0-4CF4-9F03-D4B84FCC4E59@.microsoft.com...
>> > Hi Andrew ,
>> >
>> > i was trying to shrink the log file but it couldn't as per the error
>> > below
>> > and i have also tried to shrink the database as well , hoping it'll
>> > shrink
>> > the log file
>> >
>> > tks & rdgs
>> >
>> > "Andrew J. Kelly" wrote:
>> >
>> >> Are you trying to shrink the db file or the log file? Sounds like the
>> >> log
>> >> file. You should use DBCC SHRINKFILE not database as it allows you to
>> >> choose the specific file you want to shrink and how much.
>> >>
>> >> --
>> >> Andrew J. Kelly SQL MVP
>> >>
>> >>
>> >> "maxzsim" <maxzsim@.discussions.microsoft.com> wrote in message
>> >> news:BFE5D0BA-D797-40CE-899B-246D6BA039D4@.microsoft.com...
>> >> > Hi ,
>> >> >
>> >> > i was trying to shrink a database but i got the following error :
>> >> > it's something like " logical file is in use" despite me logging in
>> >> > as
>> >> > a
>> >> > single user
>> >> >
>> >> > the statement i used : DBCC Shrinkdatabase ('dbname', 1 ,
>> >> > truncate_only)
>> >> >
>> >> > i have also used the EM's shrink database , though it says it
>> >> > completed
>> >> > successfully but it did not shrink the database
>> >> >
>> >> > kindly advise
>> >> > tks & rdgs
>> >>
>> >>
>> >>
>>

dbcc shrinkdatabase error

Wednesday, March 7, 2012

DBCC DBREINDEX not changing anything!

This is quite weird...
Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
rebuild anything in the indexes, and fragmentation remains (67%).
Am I doing something incredibly stupid here or is there an issue I need
to be aware of?
Table has non-clustered indexes on it only.
Any suggestions? Has anyone seen this behaviour before?
Thx
How big is the table? Do you have a clustered index on the table? If not
then you can rebuild til you are blue in the face and it will still stay the
same. One of the reasons why most every table should have a clustered
index.
Andrew J. Kelly SQL MVP
"Paul Buxton" <spireite@.hotmail.com> wrote in message
news:ez$QWeOGFHA.444@.TK2MSFTNGP15.phx.gbl...
> This is quite weird...
> Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
> rebuild anything in the indexes, and fragmentation remains (67%).
> Am I doing something incredibly stupid here or is there an issue I need to
> be aware of?
> Table has non-clustered indexes on it only.
> Any suggestions? Has anyone seen this behaviour before?
> Thx
|||Paul
You really need a clustered index for reindex or rebuild to be effective in
removing fragmentation. Create a clustered index and then drop it. This will
reduce your fragmentation, and due to not having a clustered index your
tables will not fragment as quickly afterwards.
Hope this helps
John
"Paul Buxton" wrote:

> This is quite weird...
> Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
> rebuild anything in the indexes, and fragmentation remains (67%).
> Am I doing something incredibly stupid here or is there an issue I need
> to be aware of?
> Table has non-clustered indexes on it only.
> Any suggestions? Has anyone seen this behaviour before?
> Thx
>
|||Andrew J. Kelly wrote:
> How big is the table? Do you have a clustered index on the table? If not
> then you can rebuild til you are blue in the face and it will still stay the
> same. One of the reasons why most every table should have a clustered
> index.
>
I thought it may be index related (hence my mentioning the indexes).
The table itself is 1Gb in size. Unfortunately, I can't change the
indexing (MSCRM - and not a clustered index in sight!) as support will
be removed if we do.
Presumably then the fallback is going to be an INDEXDEFRAG and UPDATE
STATISTICS only. Strangely, The MS CRM Performance Tuning Whitepaper
suggests running the DBREINDEX when they have no clustered indexes in
the DB.
|||John Bandettini wrote:
> Paul
> You really need a clustered index for reindex or rebuild to be effective in
> removing fragmentation. Create a clustered index and then drop it. This will
> reduce your fragmentation, and due to not having a clustered index your
> tables will not fragment as quickly afterwards.
> Hope this helps
> John
>
Sadly, I can't change the schema for the DB or create indexes as far as
I can tell. My understanding is that we lose our support if we do
(system is MS CRM).
|||Sadly, I can't change the database in anyway or we lose support (system
is MS CRM 1.2). INDEXDEFRAG/UPDATE STATISTICS is probably the best I
can do.
John Bandettini wrote:[vbcol=seagreen]
> Paul
> You really need a clustered index for reindex or rebuild to be effective in
> removing fragmentation. Create a clustered index and then drop it. This will
> reduce your fragmentation, and due to not having a clustered index your
> tables will not fragment as quickly afterwards.
> Hope this helps
> John
> "Paul Buxton" wrote:
>
|||Is it an index or the datapages you want to defrag? There is no way to defrag the data pages for a
table without a clustered index (heap table) with less than:
1 Export, truncate, import (or similar)
or
2 Create a clustered index and then drop it.
Also, if this is indeed a heap table, you need to think about that fragmentation really is for the
data pages. There is no linked list for the data pages in a heap table, so there's no jumping back
and forth. So the type of fragmentation we can talk about is if you either have non-consecutive
extents or less than full pages.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Paul Buxton" <spireite@.hotmail.com> wrote in message news:Oi4RdgQGFHA.2876@.TK2MSFTNGP12.phx.gbl...
> Andrew J. Kelly wrote:
> I thought it may be index related (hence my mentioning the indexes). The table itself is 1Gb in
> size. Unfortunately, I can't change the indexing (MSCRM - and not a clustered index in sight!) as
> support will be removed if we do.
> Presumably then the fallback is going to be an INDEXDEFRAG and UPDATE STATISTICS only. Strangely,
> The MS CRM Performance Tuning Whitepaper suggests running the DBREINDEX when they have no
> clustered indexes in the DB.
>
>
|||You should contact the vendor and tell them to get their act together and
add a proper clustered index. Why do you say that Indexdefrag is the best
option? As we all have pointed out there is nothing you can do to
defragment the tables without a CI. This is true regardless of using
DBREINDEX or INDEXEDEFRAG. As for the non-Clustered indexes (NCI's) you are
still free to use DBREINDEX on them. If you have the maintenance window to
run this you will mostly find it will be faster and cleaner than
Indexdefrag.
Andrew J. Kelly SQL MVP
"Paul Buxton" <spireite@.hotmail.com> wrote in message
news:eKau2hQGFHA.2876@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> Sadly, I can't change the database in anyway or we lose support (system is
> MS CRM 1.2). INDEXDEFRAG/UPDATE STATISTICS is probably the best I can do.
>
> John Bandettini wrote:

DBCC DBREINDEX not changing anything!

This is quite weird...
Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
rebuild anything in the indexes, and fragmentation remains (67%).
Am I doing something incredibly stupid here or is there an issue I need
to be aware of?
Table has non-clustered indexes on it only.
Any suggestions? Has anyone seen this behaviour before?
ThxHow big is the table? Do you have a clustered index on the table? If not
then you can rebuild til you are blue in the face and it will still stay the
same. One of the reasons why most every table should have a clustered
index.
Andrew J. Kelly SQL MVP
"Paul Buxton" <spireite@.hotmail.com> wrote in message
news:ez$QWeOGFHA.444@.TK2MSFTNGP15.phx.gbl...
> This is quite weird...
> Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
> rebuild anything in the indexes, and fragmentation remains (67%).
> Am I doing something incredibly stupid here or is there an issue I need to
> be aware of?
> Table has non-clustered indexes on it only.
> Any suggestions? Has anyone seen this behaviour before?
> Thx|||Paul
You really need a clustered index for reindex or rebuild to be effective in
removing fragmentation. Create a clustered index and then drop it. This will
reduce your fragmentation, and due to not having a clustered index your
tables will not fragment as quickly afterwards.
Hope this helps
John
"Paul Buxton" wrote:

> This is quite weird...
> Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
> rebuild anything in the indexes, and fragmentation remains (67%).
> Am I doing something incredibly stupid here or is there an issue I need
> to be aware of?
> Table has non-clustered indexes on it only.
> Any suggestions? Has anyone seen this behaviour before?
> Thx
>|||Andrew J. Kelly wrote:
> How big is the table? Do you have a clustered index on the table? If no
t
> then you can rebuild til you are blue in the face and it will still stay t
he
> same. One of the reasons why most every table should have a clustered
> index.
>
I thought it may be index related (hence my mentioning the indexes).
The table itself is 1Gb in size. Unfortunately, I can't change the
indexing (MSCRM - and not a clustered index in sight!) as support will
be removed if we do.
Presumably then the fallback is going to be an INDEXDEFRAG and UPDATE
STATISTICS only. Strangely, The MS CRM Performance Tuning Whitepaper
suggests running the DBREINDEX when they have no clustered indexes in
the DB.|||John Bandettini wrote:
> Paul
> You really need a clustered index for reindex or rebuild to be effective i
n
> removing fragmentation. Create a clustered index and then drop it. This wi
ll
> reduce your fragmentation, and due to not having a clustered index your
> tables will not fragment as quickly afterwards.
> Hope this helps
> John
>
Sadly, I can't change the schema for the DB or create indexes as far as
I can tell. My understanding is that we lose our support if we do
(system is MS CRM).|||Sadly, I can't change the database in anyway or we lose support (system
is MS CRM 1.2). INDEXDEFRAG/UPDATE STATISTICS is probably the best I
can do.
John Bandettini wrote:[vbcol=seagreen]
> Paul
> You really need a clustered index for reindex or rebuild to be effective i
n
> removing fragmentation. Create a clustered index and then drop it. This wi
ll
> reduce your fragmentation, and due to not having a clustered index your
> tables will not fragment as quickly afterwards.
> Hope this helps
> John
> "Paul Buxton" wrote:
>|||Is it an index or the datapages you want to defrag? There is no way to defra
g the data pages for a
table without a clustered index (heap table) with less than:
1 Export, truncate, import (or similar)
or
2 Create a clustered index and then drop it.
Also, if this is indeed a heap table, you need to think about that fragmenta
tion really is for the
data pages. There is no linked list for the data pages in a heap table, so t
here's no jumping back
and forth. So the type of fragmentation we can talk about is if you either h
ave non-consecutive
extents or less than full pages.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Paul Buxton" <spireite@.hotmail.com> wrote in message news:Oi4RdgQGFHA.2876@.TK2MSFTNGP12.phx
.gbl...
> Andrew J. Kelly wrote:
> I thought it may be index related (hence my mentioning the indexes). The t
able itself is 1Gb in
> size. Unfortunately, I can't change the indexing (MSCRM - and not a clust
ered index in sight!) as
> support will be removed if we do.
> Presumably then the fallback is going to be an INDEXDEFRAG and UPDATE STAT
ISTICS only. Strangely,
> The MS CRM Performance Tuning Whitepaper suggests running the DBREINDEX w
hen they have no
> clustered indexes in the DB.
>
>|||You should contact the vendor and tell them to get their act together and
add a proper clustered index. Why do you say that Indexdefrag is the best
option? As we all have pointed out there is nothing you can do to
defragment the tables without a CI. This is true regardless of using
DBREINDEX or INDEXEDEFRAG. As for the non-Clustered indexes (NCI's) you are
still free to use DBREINDEX on them. If you have the maintenance window to
run this you will mostly find it will be faster and cleaner than
Indexdefrag.
Andrew J. Kelly SQL MVP
"Paul Buxton" <spireite@.hotmail.com> wrote in message
news:eKau2hQGFHA.2876@.TK2MSFTNGP12.phx.gbl...[vbcol=seagreen]
> Sadly, I can't change the database in anyway or we lose support (system is
> MS CRM 1.2). INDEXDEFRAG/UPDATE STATISTICS is probably the best I can do.
>
> John Bandettini wrote:

DBCC DBREINDEX not changing anything!

This is quite weird...
Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
rebuild anything in the indexes, and fragmentation remains (67%).
Am I doing something incredibly stupid here or is there an issue I need
to be aware of?
Table has non-clustered indexes on it only.
Any suggestions? Has anyone seen this behaviour before?
ThxHow big is the table? Do you have a clustered index on the table? If not
then you can rebuild til you are blue in the face and it will still stay the
same. One of the reasons why most every table should have a clustered
index.
--
Andrew J. Kelly SQL MVP
"Paul Buxton" <spireite@.hotmail.com> wrote in message
news:ez$QWeOGFHA.444@.TK2MSFTNGP15.phx.gbl...
> This is quite weird...
> Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
> rebuild anything in the indexes, and fragmentation remains (67%).
> Am I doing something incredibly stupid here or is there an issue I need to
> be aware of?
> Table has non-clustered indexes on it only.
> Any suggestions? Has anyone seen this behaviour before?
> Thx|||Paul
You really need a clustered index for reindex or rebuild to be effective in
removing fragmentation. Create a clustered index and then drop it. This will
reduce your fragmentation, and due to not having a clustered index your
tables will not fragment as quickly afterwards.
Hope this helps
John
"Paul Buxton" wrote:
> This is quite weird...
> Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
> rebuild anything in the indexes, and fragmentation remains (67%).
> Am I doing something incredibly stupid here or is there an issue I need
> to be aware of?
> Table has non-clustered indexes on it only.
> Any suggestions? Has anyone seen this behaviour before?
> Thx
>|||Andrew J. Kelly wrote:
> How big is the table? Do you have a clustered index on the table? If not
> then you can rebuild til you are blue in the face and it will still stay the
> same. One of the reasons why most every table should have a clustered
> index.
>
I thought it may be index related (hence my mentioning the indexes).
The table itself is 1Gb in size. Unfortunately, I can't change the
indexing (MSCRM - and not a clustered index in sight!) as support will
be removed if we do.
Presumably then the fallback is going to be an INDEXDEFRAG and UPDATE
STATISTICS only. Strangely, The MS CRM Performance Tuning Whitepaper
suggests running the DBREINDEX when they have no clustered indexes in
the DB.|||John Bandettini wrote:
> Paul
> You really need a clustered index for reindex or rebuild to be effective in
> removing fragmentation. Create a clustered index and then drop it. This will
> reduce your fragmentation, and due to not having a clustered index your
> tables will not fragment as quickly afterwards.
> Hope this helps
> John
>
Sadly, I can't change the schema for the DB or create indexes as far as
I can tell. My understanding is that we lose our support if we do
(system is MS CRM).|||Sadly, I can't change the database in anyway or we lose support (system
is MS CRM 1.2). INDEXDEFRAG/UPDATE STATISTICS is probably the best I
can do.
John Bandettini wrote:
> Paul
> You really need a clustered index for reindex or rebuild to be effective in
> removing fragmentation. Create a clustered index and then drop it. This will
> reduce your fragmentation, and due to not having a clustered index your
> tables will not fragment as quickly afterwards.
> Hope this helps
> John
> "Paul Buxton" wrote:
>
>>This is quite weird...
>>Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
>>rebuild anything in the indexes, and fragmentation remains (67%).
>>Am I doing something incredibly stupid here or is there an issue I need
>>to be aware of?
>>Table has non-clustered indexes on it only.
>>Any suggestions? Has anyone seen this behaviour before?
>>Thx|||Is it an index or the datapages you want to defrag? There is no way to defrag the data pages for a
table without a clustered index (heap table) with less than:
1 Export, truncate, import (or similar)
or
2 Create a clustered index and then drop it.
Also, if this is indeed a heap table, you need to think about that fragmentation really is for the
data pages. There is no linked list for the data pages in a heap table, so there's no jumping back
and forth. So the type of fragmentation we can talk about is if you either have non-consecutive
extents or less than full pages.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
http://www.sqlug.se/
"Paul Buxton" <spireite@.hotmail.com> wrote in message news:Oi4RdgQGFHA.2876@.TK2MSFTNGP12.phx.gbl...
> Andrew J. Kelly wrote:
>> How big is the table? Do you have a clustered index on the table? If not then you can rebuild
>> til you are blue in the face and it will still stay the same. One of the reasons why most every
>> table should have a clustered index.
> I thought it may be index related (hence my mentioning the indexes). The table itself is 1Gb in
> size. Unfortunately, I can't change the indexing (MSCRM - and not a clustered index in sight!) as
> support will be removed if we do.
> Presumably then the fallback is going to be an INDEXDEFRAG and UPDATE STATISTICS only. Strangely,
> The MS CRM Performance Tuning Whitepaper suggests running the DBREINDEX when they have no
> clustered indexes in the DB.
>
>|||You should contact the vendor and tell them to get their act together and
add a proper clustered index. Why do you say that Indexdefrag is the best
option? As we all have pointed out there is nothing you can do to
defragment the tables without a CI. This is true regardless of using
DBREINDEX or INDEXEDEFRAG. As for the non-Clustered indexes (NCI's) you are
still free to use DBREINDEX on them. If you have the maintenance window to
run this you will mostly find it will be faster and cleaner than
Indexdefrag.
Andrew J. Kelly SQL MVP
"Paul Buxton" <spireite@.hotmail.com> wrote in message
news:eKau2hQGFHA.2876@.TK2MSFTNGP12.phx.gbl...
> Sadly, I can't change the database in anyway or we lose support (system is
> MS CRM 1.2). INDEXDEFRAG/UPDATE STATISTICS is probably the best I can do.
>
> John Bandettini wrote:
>> Paul
>> You really need a clustered index for reindex or rebuild to be effective
>> in removing fragmentation. Create a clustered index and then drop it.
>> This will reduce your fragmentation, and due to not having a clustered
>> index your tables will not fragment as quickly afterwards.
>> Hope this helps
>> John
>> "Paul Buxton" wrote:
>>
>>This is quite weird...
>>Despite what table I pick, running a DBCC DBREINDEX(tablename) does not
>>rebuild anything in the indexes, and fragmentation remains (67%).
>>Am I doing something incredibly stupid here or is there an issue I need
>>to be aware of?
>>Table has non-clustered indexes on it only.
>>Any suggestions? Has anyone seen this behaviour before?
>>Thx

Tuesday, March 27, 2012

dbcc shrinkdatabase error

dbcc shrinkdatabase error

dbcc shrinkdatabase error

Wednesday, March 7, 2012

DBCC DBREINDEX not changing anything!

DBCC DBREINDEX not changing anything!

DBCC DBREINDEX not changing anything!

DBfile usage

Blog Archive

About Me