repair_rebuild and the transaction log

We have a large-ish database (160GB) which grew to over 300GB last weekend
when the maintenance job failed. Half of it is unused but I can't shrink it
due to index errors and when I run checkdb it also reports index errors. I
would like to run checkdb with repair_rebuild but there is not much room for
the log file to grow now the DB has gotten so big - it will max out around
8-10GB.
My questions are:
Will repair_rebuild need the log file to grow any larger than 8GB on a 160GB
database? If so can I just move the log file to a drive with more room?
I can't copy the DB to another server and test out the repair_rebuild - does
anyone have an idea how long it will take on a 160GB database? Are we talking
several hours or days?
Is DBCC reindex a better option in my case?
Thanks
Part of DBCC CHECK With Repair_rebuild option is rebuilding corrupt
indexes. How about adding a new transaction log to a different drive
instead of moving existing log file?
Yih-Yoon Lee
J Jetson wrote:
> We have a large-ish database (160GB) which grew to over 300GB last weekend
> when the maintenance job failed. Half of it is unused but I can't shrink it
> due to index errors and when I run checkdb it also reports index errors. I
> would like to run checkdb with repair_rebuild but there is not much room for
> the log file to grow now the DB has gotten so big - it will max out around
> 8-10GB.
> My questions are:
> Will repair_rebuild need the log file to grow any larger than 8GB on a 160GB
> database? If so can I just move the log file to a drive with more room?
> I can't copy the DB to another server and test out the repair_rebuild - does
> anyone have an idea how long it will take on a 160GB database? Are we talking
> several hours or days?
> Is DBCC reindex a better option in my case?
> Thanks
|||t8-10GB is too small for 160GB db to run checkdb.
You can move log file to a big disk with detach and atach syntax and then
run check db. Alternatively, you can turn Recovery Model from "Full" to
"Simple" in DB Options.
Given that, SQL server will not grow log file. It's same as trunc. log on
chkpt in SQL 7.
Zrich
"J Jetson" wrote:

> We have a large-ish database (160GB) which grew to over 300GB last weekend
> when the maintenance job failed. Half of it is unused but I can't shrink it
> due to index errors and when I run checkdb it also reports index errors. I
> would like to run checkdb with repair_rebuild but there is not much room for
> the log file to grow now the DB has gotten so big - it will max out around
> 8-10GB.
> My questions are:
> Will repair_rebuild need the log file to grow any larger than 8GB on a 160GB
> database? If so can I just move the log file to a drive with more room?
> I can't copy the DB to another server and test out the repair_rebuild - does
> anyone have an idea how long it will take on a 160GB database? Are we talking
> several hours or days?
> Is DBCC reindex a better option in my case?
> Thanks
|||> t8-10GB is too small for 160GB db to run checkdb.
I don't know how you can possibly say that when you have no idea what
corruptions exist in the database or the size of the indexes that the
repair_rebuild option may cause to be rebuilt.
Can you post the output from DBCC CHECKDB? Also, have you done root-cause
analysis to work out why the corruption happened? (e.g. look through the SQL
errorlog and Windows event logs for hardware errors).
Regards
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Zrich" <Zrich@.discussions.microsoft.com> wrote in message
news:92D7B4F1-0637-4A56-BB98-4EE0C002239C@.microsoft.com...[vbcol=seagreen]
> t8-10GB is too small for 160GB db to run checkdb.
> You can move log file to a big disk with detach and atach syntax and then
> run check db. Alternatively, you can turn Recovery Model from "Full" to
> "Simple" in DB Options.
> Given that, SQL server will not grow log file. It's same as trunc. log on
> chkpt in SQL 7.
> Zrich
> "J Jetson" wrote:
weekend[vbcol=seagreen]
it[vbcol=seagreen]
I[vbcol=seagreen]
for[vbcol=seagreen]
around[vbcol=seagreen]
160GB[vbcol=seagreen]
does[vbcol=seagreen]
talking[vbcol=seagreen]

repair_rebuild and the transaction log

We have a large-ish database (160GB) which grew to over 300GB last weekend
when the maintenance job failed. Half of it is unused but I can't shrink it
due to index errors and when I run checkdb it also reports index errors. I
would like to run checkdb with repair_rebuild but there is not much room for
the log file to grow now the DB has gotten so big - it will max out around
8-10GB.
My questions are:
Will repair_rebuild need the log file to grow any larger than 8GB on a 160GB
database? If so can I just move the log file to a drive with more room?
I can't copy the DB to another server and test out the repair_rebuild - does
anyone have an idea how long it will take on a 160GB database? Are we talkin
g
several hours or days?
Is DBCC reindex a better option in my case?
ThanksPart of DBCC CHECK With Repair_rebuild option is rebuilding corrupt
indexes. How about adding a new transaction log to a different drive
instead of moving existing log file?
Yih-Yoon Lee
J Jetson wrote:
> We have a large-ish database (160GB) which grew to over 300GB last weekend
> when the maintenance job failed. Half of it is unused but I can't shrink i
t
> due to index errors and when I run checkdb it also reports index errors. I
> would like to run checkdb with repair_rebuild but there is not much room f
or
> the log file to grow now the DB has gotten so big - it will max out around
> 8-10GB.
> My questions are:
> Will repair_rebuild need the log file to grow any larger than 8GB on a 160
GB
> database? If so can I just move the log file to a drive with more room?
> I can't copy the DB to another server and test out the repair_rebuild - do
es
> anyone have an idea how long it will take on a 160GB database? Are we talk
ing
> several hours or days?
> Is DBCC reindex a better option in my case?
> Thanks|||t8-10GB is too small for 160GB db to run checkdb.
You can move log file to a big disk with detach and atach syntax and then
run check db. Alternatively, you can turn Recovery Model from "Full" to
"Simple" in DB Options.
Given that, SQL server will not grow log file. It's same as trunc. log on
chkpt in SQL 7.
Zrich
"J Jetson" wrote:

> We have a large-ish database (160GB) which grew to over 300GB last weekend
> when the maintenance job failed. Half of it is unused but I can't shrink i
t
> due to index errors and when I run checkdb it also reports index errors. I
> would like to run checkdb with repair_rebuild but there is not much room f
or
> the log file to grow now the DB has gotten so big - it will max out around
> 8-10GB.
> My questions are:
> Will repair_rebuild need the log file to grow any larger than 8GB on a 160
GB
> database? If so can I just move the log file to a drive with more room?
> I can't copy the DB to another server and test out the repair_rebuild - do
es
> anyone have an idea how long it will take on a 160GB database? Are we talk
ing
> several hours or days?
> Is DBCC reindex a better option in my case?
> Thanks|||> t8-10GB is too small for 160GB db to run checkdb.
I don't know how you can possibly say that when you have no idea what
corruptions exist in the database or the size of the indexes that the
repair_rebuild option may cause to be rebuilt.
Can you post the output from DBCC CHECKDB? Also, have you done root-cause
analysis to work out why the corruption happened? (e.g. look through the SQL
errorlog and Windows event logs for hardware errors).
Regards
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Zrich" <Zrich@.discussions.microsoft.com> wrote in message
news:92D7B4F1-0637-4A56-BB98-4EE0C002239C@.microsoft.com...[vbcol=seagreen]
> t8-10GB is too small for 160GB db to run checkdb.
> You can move log file to a big disk with detach and atach syntax and then
> run check db. Alternatively, you can turn Recovery Model from "Full" to
> "Simple" in DB Options.
> Given that, SQL server will not grow log file. It's same as trunc. log on
> chkpt in SQL 7.
> Zrich
> "J Jetson" wrote:
>
weekend[vbcol=seagreen]
it[vbcol=seagreen]
I[vbcol=seagreen]
for[vbcol=seagreen]
around[vbcol=seagreen]
160GB[vbcol=seagreen]
does[vbcol=seagreen]
talking[vbcol=seagreen]

repair_rebuild and the transaction log

We have a large-ish database (160GB) which grew to over 300GB last weekend
when the maintenance job failed. Half of it is unused but I can't shrink it
due to index errors and when I run checkdb it also reports index errors. I
would like to run checkdb with repair_rebuild but there is not much room for
the log file to grow now the DB has gotten so big - it will max out around
8-10GB.
My questions are:
Will repair_rebuild need the log file to grow any larger than 8GB on a 160GB
database? If so can I just move the log file to a drive with more room?
I can't copy the DB to another server and test out the repair_rebuild - does
anyone have an idea how long it will take on a 160GB database? Are we talking
several hours or days?
Is DBCC reindex a better option in my case?
ThanksPart of DBCC CHECK With Repair_rebuild option is rebuilding corrupt
indexes. How about adding a new transaction log to a different drive
instead of moving existing log file?
Yih-Yoon Lee
J Jetson wrote:
> We have a large-ish database (160GB) which grew to over 300GB last weekend
> when the maintenance job failed. Half of it is unused but I can't shrink it
> due to index errors and when I run checkdb it also reports index errors. I
> would like to run checkdb with repair_rebuild but there is not much room for
> the log file to grow now the DB has gotten so big - it will max out around
> 8-10GB.
> My questions are:
> Will repair_rebuild need the log file to grow any larger than 8GB on a 160GB
> database? If so can I just move the log file to a drive with more room?
> I can't copy the DB to another server and test out the repair_rebuild - does
> anyone have an idea how long it will take on a 160GB database? Are we talking
> several hours or days?
> Is DBCC reindex a better option in my case?
> Thanks|||t8-10GB is too small for 160GB db to run checkdb.
You can move log file to a big disk with detach and atach syntax and then
run check db. Alternatively, you can turn Recovery Model from "Full" to
"Simple" in DB Options.
Given that, SQL server will not grow log file. It's same as trunc. log on
chkpt in SQL 7.
Zrich
"J Jetson" wrote:
> We have a large-ish database (160GB) which grew to over 300GB last weekend
> when the maintenance job failed. Half of it is unused but I can't shrink it
> due to index errors and when I run checkdb it also reports index errors. I
> would like to run checkdb with repair_rebuild but there is not much room for
> the log file to grow now the DB has gotten so big - it will max out around
> 8-10GB.
> My questions are:
> Will repair_rebuild need the log file to grow any larger than 8GB on a 160GB
> database? If so can I just move the log file to a drive with more room?
> I can't copy the DB to another server and test out the repair_rebuild - does
> anyone have an idea how long it will take on a 160GB database? Are we talking
> several hours or days?
> Is DBCC reindex a better option in my case?
> Thanks|||> t8-10GB is too small for 160GB db to run checkdb.
I don't know how you can possibly say that when you have no idea what
corruptions exist in the database or the size of the indexes that the
repair_rebuild option may cause to be rebuilt.
Can you post the output from DBCC CHECKDB? Also, have you done root-cause
analysis to work out why the corruption happened? (e.g. look through the SQL
errorlog and Windows event logs for hardware errors).
Regards
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Zrich" <Zrich@.discussions.microsoft.com> wrote in message
news:92D7B4F1-0637-4A56-BB98-4EE0C002239C@.microsoft.com...
> t8-10GB is too small for 160GB db to run checkdb.
> You can move log file to a big disk with detach and atach syntax and then
> run check db. Alternatively, you can turn Recovery Model from "Full" to
> "Simple" in DB Options.
> Given that, SQL server will not grow log file. It's same as trunc. log on
> chkpt in SQL 7.
> Zrich
> "J Jetson" wrote:
> > We have a large-ish database (160GB) which grew to over 300GB last
weekend
> > when the maintenance job failed. Half of it is unused but I can't shrink
it
> > due to index errors and when I run checkdb it also reports index errors.
I
> > would like to run checkdb with repair_rebuild but there is not much room
for
> > the log file to grow now the DB has gotten so big - it will max out
around
> > 8-10GB.
> >
> > My questions are:
> >
> > Will repair_rebuild need the log file to grow any larger than 8GB on a
160GB
> > database? If so can I just move the log file to a drive with more room?
> >
> > I can't copy the DB to another server and test out the repair_rebuild -
does
> > anyone have an idea how long it will take on a 160GB database? Are we
talking
> > several hours or days?
> >
> > Is DBCC reindex a better option in my case?
> >
> > Thanks

Repair database that grew over 2 GB

Because of a configuration error by field engineer who didn't check the
error logs before leaving, an error logging table in an MSDE database has
made it grow to 2GB in a couple of days.
The result is that the database status became "suspect" (I had to connect
through enterprise manager to see that) and it can no longer be opened.
At the same time, I noticed that the $&*$##% has renamed the computer after
installing MSDE and initializing the database, despite my urging him never
to do so: as a result the backup schedule that's created along with the
database was no longer executed, the last backup dates from last April
instead of a few hours before it stopped working.
Needless to say that the customer is very happy.
Now I think I made an additional error by trying to detach and re-attach
the database: MSDE won't even re-attach it anymore, with an error "the
primary file group is full".
Is there a way to force MSDE to load it anyway so the extraneous data can
be deleted?
Can the file be attached to a full SQL server, the runaway table purged
there, and then re-attached to MSDE?
Sorry, it seems I clicked 'Reply' in stead of 'new post' by mistake.

Repair database that grew over 2 GB

Because of a configuration error by field engineer who didn't check the
error logs before leaving, an error logging table in an MSDE database has
made it grow to 2GB in a couple of days.
The result is that the database status became "suspect" (I had to connect
through enterprise manager to see that) and it can no longer be opened.
At the same time, I noticed that the $&*$##% has renamed the computer after
installing MSDE and initializing the database, despite my urging him never
to do so: as a result the backup schedule that's created along with the
database was no longer executed, the last backup dates from last April
instead of a few hours before it stopped working.
Needless to say that the customer is very happy.
Now I think I made an additional error by trying to detach and re-attach
the database: MSDE won't even re-attach it anymore, with an error "the
primary file group is full".
Is there a way to force MSDE to load it anyway so the extraneous data can
be deleted?
Can the file be attached to a full SQL server, the runaway table purged
there, and then re-attached to MSDE?
On Tue, 28 Dec 2004 12:14:46 +0100, Lucvdv <replace_name@.null.net> wrote:

> Because of a configuration error by field engineer who didn't check the
> error logs before leaving, an error logging table in an MSDE database has
> made it grow to 2GB in a couple of days.
I just tried to recreate the problem on a test machine: the .mdf file grew
to 1869 MB (1.82 GB), then it stopped with "PRIMARY file group full", but
the database remains accessible, only inserts fail.
In the problem case, the .mdf file was slightly over 2 GB (2.03GB or so, I
don't remember exactly.)
Is there an explanation for this?
|||On Tue, 28 Dec 2004 12:14:46 +0100, Lucvdv <replace_name@.null.net> wrote:

> Can the file be attached to a full SQL server, the runaway table purged
> there, and then re-attached to MSDE?
Relief all around: after copying and attaching the database to a full SQL
Server, shrinking it there and then moving it back to MSDE, everything is
up and running again.
|||hi,
"Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
news:ivf2t0ln44sb9r9ll8ucnknidv4pg4ppad@.4ax.com
> ...
> Can the file be attached to a full SQL server, the runaway table
> purged there, and then re-attached to MSDE?
yes... you can get the mdf (+ ndf if present) + ldf database files set,
take them to your office, purge the "extra" data and shrink the database
data file(s) to a size allowed by MSDE..
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply
|||On Tue, 28 Dec 2004 17:12:37 +0100, "Andrea Montanari"
<andrea.sqlDMO@.virgilio.it> wrote:

> hi,
> "Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
> news:ivf2t0ln44sb9r9ll8ucnknidv4pg4ppad@.4ax.com
> yes... you can get the mdf (+ ndf if present) + ldf database files set,
> take them to your office, purge the "extra" data and shrink the database
> data file(s) to a size allowed by MSDE..
Thanks. I had tried and found that it worked shortly before you replied.
I tried to repeat it on a test machine later, but couldn't make the .mdf
grow above 2GB: all inserts started failing when the final file grow step
had to be done. It actually stopped around 1850 MB with % growth steps, it
refused to go closer to 2G until I changed that to 5MB fixed increments,
and then it stopped at 2044 MB.
The database remained usable, I could detach and attach it, only inserts
failed.
Yet in the problem case it was 2.03GB or something like that (slightly
above 2GB anyway), and MSDE refused to use it any further.
Do you have an idea how that might have happened?
I also noticed when I changed the file growth settings from % to fixed
size, that the change didn't take effect until I had detached and
re-attached the database (rebooting or restarting the service would
probably have done it too, what I mean is that inserts didn't start working
again by just changing the setting).
Is that something known?
|||hi Lucvdv,
"Lucvdv" <replace_name@.null.net> ha scritto nel messaggio
news:94r4t0p6bvclndb2l8gjuhogmd9ho8hq00@.4ax.com
> ...
> I tried to repeat it on a test machine later, but couldn't make the
> .mdf grow above 2GB: all inserts started failing when the final file
> grow step had to be done. It actually stopped around 1850 MB with %
> growth steps, it refused to go closer to 2G until I changed that to
> 5MB fixed increments, and then it stopped at 2044 MB.
> The database remained usable, I could detach and attach it, only
> inserts failed.
> Yet in the problem case it was 2.03GB or something like that (slightly
> above 2GB anyway), and MSDE refused to use it any further.
> Do you have an idea how that might have happened?
>
> I also noticed when I changed the file growth settings from % to fixed
> size, that the change didn't take effect until I had detached and
> re-attached the database (rebooting or restarting the service would
> probably have done it too, what I mean is that inserts didn't start
> working again by just changing the setting).
> Is that something known?
AFAIK the Storage engine should throw an exception when the 2gb limit is
reached, but should not set the db in suspect mode... this is what I've been
always told, as I never pushed MSDE to that upper limit :D ...
and this is the very first time I hear about growth setting affect such a
behaviour.. will try investigating this...
Andrea Montanari (Microsoft MVP - SQL Server)
http://www.asql.biz/DbaMgr.shtmhttp://italy.mvps.org
DbaMgr2k ver 0.9.1 - DbaMgr ver 0.55.1
(my vb6+sql-dmo little try to provide MS MSDE 1.0 and MSDE 2000 a visual
interface)
-- remove DMO to reply