check sql licence: checktable

Showing posts with label checktable. Show all posts

Thursday, March 8, 2012

checktable with repair_rebuild

Hi! Could anyone tell me how much free space is needed to run DBCC
Checktable with repair_rebuild option. I have a table with more than 100
million record with size around 120 G and when I ran the command it failed
because of space issue. I only had around 50 G. of free space left on that
drive.
Does it require same free space as in DBCC DBReindex (1.2 * Table)? Is there
any command that I can use to use Tempdb for the rebuild process instead of
using the database space?
I appreciate your answer.If your running 2000 then you can specify the ESTIMATE_ONLY option to see
how much space you need in tempdb. Check out BOL for more details.
--
Andrew J. Kelly SQL MVP
"james" <kush@.brandes.com> wrote in message
news:%23u9f%23UNJEHA.2604@.tk2msftngp13.phx.gbl...
> Hi! Could anyone tell me how much free space is needed to run DBCC
> Checktable with repair_rebuild option. I have a table with more than 100
> million record with size around 120 G and when I ran the command it failed
> because of space issue. I only had around 50 G. of free space left on that
> drive.
> Does it require same free space as in DBCC DBReindex (1.2 * Table)? Is
there
> any command that I can use to use Tempdb for the rebuild process instead
of
> using the database space?
> I appreciate your answer.
>
>|||However the ESTIMATEONLY option only works out how much space is required to
run the check - it does not know what repairs may be necessary and how much
space they will require. For an index rebuild, you will need the same amount
of free space as if you were running DBCC DBREINDEX on the same index.
BTW, if you have determined that there is an integrity problem, it is in
your best interestes to do root-cause analysis of the problem and see why it
happened (almost certainly hardware). Examine your event logs, the SQL
Server error logs and run any hardware diagnostics you can - the odds are it
will happen again.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Andrew J. Kelly" <sqlmvpnoooospam@.shadhawk.com> wrote in message
news:OAWZVyOJEHA.2508@.TK2MSFTNGP10.phx.gbl...
> If your running 2000 then you can specify the ESTIMATE_ONLY option to see
> how much space you need in tempdb. Check out BOL for more details.
> --
> Andrew J. Kelly SQL MVP
>
> "james" <kush@.brandes.com> wrote in message
> news:%23u9f%23UNJEHA.2604@.tk2msftngp13.phx.gbl...
> > Hi! Could anyone tell me how much free space is needed to run DBCC
> > Checktable with repair_rebuild option. I have a table with more than 100
> > million record with size around 120 G and when I ran the command it
failed
> > because of space issue. I only had around 50 G. of free space left on
that
> > drive.
> > Does it require same free space as in DBCC DBReindex (1.2 * Table)? Is
> there
> > any command that I can use to use Tempdb for the rebuild process instead
> of
> > using the database space?
> >
> > I appreciate your answer.
> >
> >
> >
>|||Thanks for the answer.
In order to find what may have caused this, our Network guys did some online
hardware diognistic and didn't see any problems. Now we are planning to do
offline diognistic. I have one question on this:
Is there any specifc hardware (disk i/o, cpu, memory etc) do we need to
focus on? In other words what has been the main culprit from hardware side
causing database corruption, in your experience?
I appreciate your answer.
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:eYh248UJEHA.3436@.tk2msftngp13.phx.gbl...
> However the ESTIMATEONLY option only works out how much space is required
to
> run the check - it does not know what repairs may be necessary and how
much
> space they will require. For an index rebuild, you will need the same
amount
> of free space as if you were running DBCC DBREINDEX on the same index.
> BTW, if you have determined that there is an integrity problem, it is in
> your best interestes to do root-cause analysis of the problem and see why
it
> happened (almost certainly hardware). Examine your event logs, the SQL
> Server error logs and run any hardware diagnostics you can - the odds are
it
> will happen again.
> Regards.
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Andrew J. Kelly" <sqlmvpnoooospam@.shadhawk.com> wrote in message
> news:OAWZVyOJEHA.2508@.TK2MSFTNGP10.phx.gbl...
> > If your running 2000 then you can specify the ESTIMATE_ONLY option to
see
> > how much space you need in tempdb. Check out BOL for more details.
> >
> > --
> > Andrew J. Kelly SQL MVP
> >
> >
> > "james" <kush@.brandes.com> wrote in message
> > news:%23u9f%23UNJEHA.2604@.tk2msftngp13.phx.gbl...
> > > Hi! Could anyone tell me how much free space is needed to run DBCC
> > > Checktable with repair_rebuild option. I have a table with more than
100
> > > million record with size around 120 G and when I ran the command it
> failed
> > > because of space issue. I only had around 50 G. of free space left on
> that
> > > drive.
> > > Does it require same free space as in DBCC DBReindex (1.2 * Table)? Is
> > there
> > > any command that I can use to use Tempdb for the rebuild process
instead
> > of
> > > using the database space?
> > >
> > > I appreciate your answer.
> > >
> > >
> > >
> >
> >
>|||In my experience, the major culprits have been bad drives, cables and
occasional problems with controllers. Make sure you're on the latest
software rev for all your controllers etc.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"james" <kush@.brandes.com> wrote in message
news:uSAp727JEHA.2452@.TK2MSFTNGP09.phx.gbl...
> Thanks for the answer.
> In order to find what may have caused this, our Network guys did some
online
> hardware diognistic and didn't see any problems. Now we are planning to do
> offline diognistic. I have one question on this:
> Is there any specifc hardware (disk i/o, cpu, memory etc) do we need to
> focus on? In other words what has been the main culprit from hardware side
> causing database corruption, in your experience?
> I appreciate your answer.
>
> "Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
> news:eYh248UJEHA.3436@.tk2msftngp13.phx.gbl...
> > However the ESTIMATEONLY option only works out how much space is
required
> to
> > run the check - it does not know what repairs may be necessary and how
> much
> > space they will require. For an index rebuild, you will need the same
> amount
> > of free space as if you were running DBCC DBREINDEX on the same index.
> >
> > BTW, if you have determined that there is an integrity problem, it is in
> > your best interestes to do root-cause analysis of the problem and see
why
> it
> > happened (almost certainly hardware). Examine your event logs, the SQL
> > Server error logs and run any hardware diagnostics you can - the odds
are
> it
> > will happen again.
> >
> > Regards.
> >
> > --
> > Paul Randal
> > Dev Lead, Microsoft SQL Server Storage Engine
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> > "Andrew J. Kelly" <sqlmvpnoooospam@.shadhawk.com> wrote in message
> > news:OAWZVyOJEHA.2508@.TK2MSFTNGP10.phx.gbl...
> > > If your running 2000 then you can specify the ESTIMATE_ONLY option to
> see
> > > how much space you need in tempdb. Check out BOL for more details.
> > >
> > > --
> > > Andrew J. Kelly SQL MVP
> > >
> > >
> > > "james" <kush@.brandes.com> wrote in message
> > > news:%23u9f%23UNJEHA.2604@.tk2msftngp13.phx.gbl...
> > > > Hi! Could anyone tell me how much free space is needed to run DBCC
> > > > Checktable with repair_rebuild option. I have a table with more than
> 100
> > > > million record with size around 120 G and when I ran the command it
> > failed
> > > > because of space issue. I only had around 50 G. of free space left
on
> > that
> > > > drive.
> > > > Does it require same free space as in DBCC DBReindex (1.2 * Table)?
Is
> > > there
> > > > any command that I can use to use Tempdb for the rebuild process
> instead
> > > of
> > > > using the database space?
> > > >
> > > > I appreciate your answer.
> > > >
> > > >
> > > >
> > >
> > >
> >
> >
>|||> In order to find what may have caused this, our Network guys did some
online
> hardware diognistic and didn't see any problems. Now we are planning to do
> offline diognistic.
--
Hi James,
You should also consider SQLIOStress tool in your battery of tests:
HOW TO: Use the SQLIOStress Utility to Stress a Disk Subsystem Such As SQL
Server
http://support.microsoft.com/?id=231619
Hope this helps,
--
Eric Cárdenas
SQL Server senior support professional

checktable with repair_rebuild

checktable repair_rebuild taking long time

Hi! I am running dbcc checktable with repair_rebuild option for a table of
121 Million record (about 150 GB) in size and its already running for 74
hours and still going. Table had Keys out of order on page (1:11667248),
slots 5 and 6 (Which was clustered Index).
Could anyone tell me how long does it normally take to run this command for
table of this size? Is there any way we can see the status of process (how
far it has gone percentage wise)?
Environment:
Sql 2k SP2 running on Wi2k Advanced server
8 CPU 2.7 GH and 8 GB RAM.
I would check out Kalen Delaney's article on the sysprocesses table at www.sqlmag.com.
Check the delta of the CPU usage in sysprocesses to determine how much progress the check is making.
|||It's rebuilding the clustered index and all the non-clustered indexes as
part of the repair - depending on how much and the distribution of free
space this could take a while but I wouldn't expect it to take that long.
What was the exact output from checkdb before you re-ran with repair? You'd
have been much better off restoring from your backups (which is the
recommeneded strategy)
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"james" <kush@.brandes.com> wrote in message
news:eoZKA1PPEHA.3052@.TK2MSFTNGP12.phx.gbl...
> Hi! I am running dbcc checktable with repair_rebuild option for a table of
> 121 Million record (about 150 GB) in size and its already running for 74
> hours and still going. Table had Keys out of order on page (1:11667248),
> slots 5 and 6 (Which was clustered Index).
> Could anyone tell me how long does it normally take to run this command
for
> table of this size? Is there any way we can see the status of process (how
> far it has gone percentage wise)?
> Environment:
> Sql 2k SP2 running on Wi2k Advanced server
> 8 CPU 2.7 GH and 8 GB RAM.
>
|||I end up cancelling the job because it was already running for 78 hours and
still going. following was the result of checktable:
Server: Msg 2511, Level 16, State 2, Line 1
Table error: Object ID 437576597, Index ID 0. Keys out of order on page
(1:11667248), slots 5 and 6.
DBCC results for 'TableA'.
There are 100344909 rows in 13487540 pages for object 'TableA'.
CHECKTABLE found 0 allocation errors and 1 consistency errors in table
'TableA'(object ID 437576597).
repair_rebuild is the minimum repair level for the errors found by DBCC
CHECKTABLE (DatabaseA.dbo.TableA ).
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:%23NmJWGcPEHA.540@.TK2MSFTNGP11.phx.gbl...
> It's rebuilding the clustered index and all the non-clustered indexes as
> part of the repair - depending on how much and the distribution of free
> space this could take a while but I wouldn't expect it to take that long.
> What was the exact output from checkdb before you re-ran with repair?
You'd
> have been much better off restoring from your backups (which is the
> recommeneded strategy)
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.[vbcol=seagreen]
> "james" <kush@.brandes.com> wrote in message
> news:eoZKA1PPEHA.3052@.TK2MSFTNGP12.phx.gbl...
of[vbcol=seagreen]
> for
(how
>
|||So there are three problems here:
1) why did the corruption happen?
2) why did repair take so long?
3) removing the corruption
3) is easy - simply rebuild the index - that's all repair was doing.
However, you should run a full checkdb first as I suspect the answer to 2)
is that you have other corruptions in the database. If the checkdb comes up
clean, there's something more insidious happening and you should call PSS to
help determine the cause.
To do root-cause analysis for 1), you should check through all relevant logs
(NT event and SQL) for hardware problems, check whether there are any known
issues fixed in SP3+ that could be the problem. Again, PSS can help you with
this.
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"james" <kush@.brandes.com> wrote in message
news:#pgDF6ePEHA.620@.TK2MSFTNGP10.phx.gbl...
> I end up cancelling the job because it was already running for 78 hours
and[vbcol=seagreen]
> still going. following was the result of checktable:
> Server: Msg 2511, Level 16, State 2, Line 1
> Table error: Object ID 437576597, Index ID 0. Keys out of order on page
> (1:11667248), slots 5 and 6.
> DBCC results for 'TableA'.
> There are 100344909 rows in 13487540 pages for object 'TableA'.
> CHECKTABLE found 0 allocation errors and 1 consistency errors in table
> 'TableA'(object ID 437576597).
> repair_rebuild is the minimum repair level for the errors found by DBCC
> CHECKTABLE (DatabaseA.dbo.TableA ).
> "Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
> news:%23NmJWGcPEHA.540@.TK2MSFTNGP11.phx.gbl...
long.[vbcol=seagreen]
> You'd
> rights.
table[vbcol=seagreen]
> of
74[vbcol=seagreen]
(1:11667248),[vbcol=seagreen]
command
> (how
>

checktable repair_rebuild taking long time

Hi! I am running dbcc checktable with repair_rebuild option for a table of
121 Million record (about 150 GB) in size and its already running for 74
hours and still going. Table had Keys out of order on page (1:11667248),
slots 5 and 6 (Which was clustered Index).
Could anyone tell me how long does it normally take to run this command for
table of this size? Is there any way we can see the status of process (how
far it has gone percentage wise)?
Environment:
Sql 2k SP2 running on Wi2k Advanced server
8 CPU 2.7 GH and 8 GB RAM.I would check out Kalen Delaney's article on the sysprocesses table at com." target="_blank">www.sqlmag.
com.
Check the delta of the CPU usage in sysprocesses to determine how much progr
ess the check is making.|||It's rebuilding the clustered index and all the non-clustered indexes as
part of the repair - depending on how much and the distribution of free
space this could take a while but I wouldn't expect it to take that long.
What was the exact output from checkdb before you re-ran with repair? You'd
have been much better off restoring from your backups (which is the
recommeneded strategy)
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"james" <kush@.brandes.com> wrote in message
news:eoZKA1PPEHA.3052@.TK2MSFTNGP12.phx.gbl...
> Hi! I am running dbcc checktable with repair_rebuild option for a table of
> 121 Million record (about 150 GB) in size and its already running for 74
> hours and still going. Table had Keys out of order on page (1:11667248),
> slots 5 and 6 (Which was clustered Index).
> Could anyone tell me how long does it normally take to run this command
for
> table of this size? Is there any way we can see the status of process (how
> far it has gone percentage wise)?
> Environment:
> Sql 2k SP2 running on Wi2k Advanced server
> 8 CPU 2.7 GH and 8 GB RAM.
>|||I end up cancelling the job because it was already running for 78 hours and
still going. following was the result of checktable:
Server: Msg 2511, Level 16, State 2, Line 1
Table error: Object ID 437576597, Index ID 0. Keys out of order on page
(1:11667248), slots 5 and 6.
DBCC results for 'TableA'.
There are 100344909 rows in 13487540 pages for object 'TableA'.
CHECKTABLE found 0 allocation errors and 1 consistency errors in table
'TableA'(object ID 437576597).
repair_rebuild is the minimum repair level for the errors found by DBCC
CHECKTABLE (DatabaseA.dbo.TableA ).
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:%23NmJWGcPEHA.540@.TK2MSFTNGP11.phx.gbl...
> It's rebuilding the clustered index and all the non-clustered indexes as
> part of the repair - depending on how much and the distribution of free
> space this could take a while but I wouldn't expect it to take that long.
> What was the exact output from checkdb before you re-ran with repair?
You'd
> have been much better off restoring from your backups (which is the
> recommeneded strategy)
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "james" <kush@.brandes.com> wrote in message
> news:eoZKA1PPEHA.3052@.TK2MSFTNGP12.phx.gbl...
of[vbcol=seagreen]
> for
(how[vbcol=seagreen]
>|||So there are three problems here:
1) why did the corruption happen?
2) why did repair take so long?
3) removing the corruption
3) is easy - simply rebuild the index - that's all repair was doing.
However, you should run a full checkdb first as I suspect the answer to 2)
is that you have other corruptions in the database. If the checkdb comes up
clean, there's something more insidious happening and you should call PSS to
help determine the cause.
To do root-cause analysis for 1), you should check through all relevant logs
(NT event and SQL) for hardware problems, check whether there are any known
issues fixed in SP3+ that could be the problem. Again, PSS can help you with
this.
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"james" <kush@.brandes.com> wrote in message
news:#pgDF6ePEHA.620@.TK2MSFTNGP10.phx.gbl...
> I end up cancelling the job because it was already running for 78 hours
and
> still going. following was the result of checktable:
> Server: Msg 2511, Level 16, State 2, Line 1
> Table error: Object ID 437576597, Index ID 0. Keys out of order on page
> (1:11667248), slots 5 and 6.
> DBCC results for 'TableA'.
> There are 100344909 rows in 13487540 pages for object 'TableA'.
> CHECKTABLE found 0 allocation errors and 1 consistency errors in table
> 'TableA'(object ID 437576597).
> repair_rebuild is the minimum repair level for the errors found by DBCC
> CHECKTABLE (DatabaseA.dbo.TableA ).
> "Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
> news:%23NmJWGcPEHA.540@.TK2MSFTNGP11.phx.gbl...
long.[vbcol=seagreen]
> You'd
> rights.
table[vbcol=seagreen]
> of
74[vbcol=seagreen]
(1:11667248),[vbcol=seagreen]
command[vbcol=seagreen]
> (how
>

checktable repair_rebuild taking long time

Hi! I am running dbcc checktable with repair_rebuild option for a table of
121 Million record (about 150 GB) in size and its already running for 74
hours and still going. Table had Keys out of order on page (1:11667248),
slots 5 and 6 (Which was clustered Index).
Could anyone tell me how long does it normally take to run this command for
table of this size? Is there any way we can see the status of process (how
far it has gone percentage wise)?
Environment:
Sql 2k SP2 running on Wi2k Advanced server
8 CPU 2.7 GH and 8 GB RAM.I would check out Kalen Delaney's article on the sysprocesses table at www.sqlmag.com
Check the delta of the CPU usage in sysprocesses to determine how much progress the check is making.|||It's rebuilding the clustered index and all the non-clustered indexes as
part of the repair - depending on how much and the distribution of free
space this could take a while but I wouldn't expect it to take that long.
What was the exact output from checkdb before you re-ran with repair? You'd
have been much better off restoring from your backups (which is the
recommeneded strategy)
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"james" <kush@.brandes.com> wrote in message
news:eoZKA1PPEHA.3052@.TK2MSFTNGP12.phx.gbl...
> Hi! I am running dbcc checktable with repair_rebuild option for a table of
> 121 Million record (about 150 GB) in size and its already running for 74
> hours and still going. Table had Keys out of order on page (1:11667248),
> slots 5 and 6 (Which was clustered Index).
> Could anyone tell me how long does it normally take to run this command
for
> table of this size? Is there any way we can see the status of process (how
> far it has gone percentage wise)?
> Environment:
> Sql 2k SP2 running on Wi2k Advanced server
> 8 CPU 2.7 GH and 8 GB RAM.
>|||I end up cancelling the job because it was already running for 78 hours and
still going. following was the result of checktable:
Server: Msg 2511, Level 16, State 2, Line 1
Table error: Object ID 437576597, Index ID 0. Keys out of order on page
(1:11667248), slots 5 and 6.
DBCC results for 'TableA'.
There are 100344909 rows in 13487540 pages for object 'TableA'.
CHECKTABLE found 0 allocation errors and 1 consistency errors in table
'TableA'(object ID 437576597).
repair_rebuild is the minimum repair level for the errors found by DBCC
CHECKTABLE (DatabaseA.dbo.TableA ).
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:%23NmJWGcPEHA.540@.TK2MSFTNGP11.phx.gbl...
> It's rebuilding the clustered index and all the non-clustered indexes as
> part of the repair - depending on how much and the distribution of free
> space this could take a while but I wouldn't expect it to take that long.
> What was the exact output from checkdb before you re-ran with repair?
You'd
> have been much better off restoring from your backups (which is the
> recommeneded strategy)
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "james" <kush@.brandes.com> wrote in message
> news:eoZKA1PPEHA.3052@.TK2MSFTNGP12.phx.gbl...
> > Hi! I am running dbcc checktable with repair_rebuild option for a table
of
> > 121 Million record (about 150 GB) in size and its already running for 74
> > hours and still going. Table had Keys out of order on page (1:11667248),
> > slots 5 and 6 (Which was clustered Index).
> > Could anyone tell me how long does it normally take to run this command
> for
> > table of this size? Is there any way we can see the status of process
(how
> > far it has gone percentage wise)?
> > Environment:
> > Sql 2k SP2 running on Wi2k Advanced server
> > 8 CPU 2.7 GH and 8 GB RAM.
> >
> >
>|||So there are three problems here:
1) why did the corruption happen?
2) why did repair take so long?
3) removing the corruption
3) is easy - simply rebuild the index - that's all repair was doing.
However, you should run a full checkdb first as I suspect the answer to 2)
is that you have other corruptions in the database. If the checkdb comes up
clean, there's something more insidious happening and you should call PSS to
help determine the cause.
To do root-cause analysis for 1), you should check through all relevant logs
(NT event and SQL) for hardware problems, check whether there are any known
issues fixed in SP3+ that could be the problem. Again, PSS can help you with
this.
Regards.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"james" <kush@.brandes.com> wrote in message
news:#pgDF6ePEHA.620@.TK2MSFTNGP10.phx.gbl...
> I end up cancelling the job because it was already running for 78 hours
and
> still going. following was the result of checktable:
> Server: Msg 2511, Level 16, State 2, Line 1
> Table error: Object ID 437576597, Index ID 0. Keys out of order on page
> (1:11667248), slots 5 and 6.
> DBCC results for 'TableA'.
> There are 100344909 rows in 13487540 pages for object 'TableA'.
> CHECKTABLE found 0 allocation errors and 1 consistency errors in table
> 'TableA'(object ID 437576597).
> repair_rebuild is the minimum repair level for the errors found by DBCC
> CHECKTABLE (DatabaseA.dbo.TableA ).
> "Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
> news:%23NmJWGcPEHA.540@.TK2MSFTNGP11.phx.gbl...
> > It's rebuilding the clustered index and all the non-clustered indexes as
> > part of the repair - depending on how much and the distribution of free
> > space this could take a while but I wouldn't expect it to take that
long.
> > What was the exact output from checkdb before you re-ran with repair?
> You'd
> > have been much better off restoring from your backups (which is the
> > recommeneded strategy)
> >
> > --
> > Paul Randal
> > Dev Lead, Microsoft SQL Server Storage Engine
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> >
> > "james" <kush@.brandes.com> wrote in message
> > news:eoZKA1PPEHA.3052@.TK2MSFTNGP12.phx.gbl...
> > > Hi! I am running dbcc checktable with repair_rebuild option for a
table
> of
> > > 121 Million record (about 150 GB) in size and its already running for
74
> > > hours and still going. Table had Keys out of order on page
(1:11667248),
> > > slots 5 and 6 (Which was clustered Index).
> > > Could anyone tell me how long does it normally take to run this
command
> > for
> > > table of this size? Is there any way we can see the status of process
> (how
> > > far it has gone percentage wise)?
> > > Environment:
> > > Sql 2k SP2 running on Wi2k Advanced server
> > > 8 CPU 2.7 GH and 8 GB RAM.
> > >
> > >
> >
> >
>

checktable error

I receive the following after running checktable:
CHECKTABLE found 0 allocation errors and 2 consistency errors in table
'RequestWords' (object ID 910678342).
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKTABLE (synergy.dbo.RequestWords ).
I have a backup and would like to know the best way to proceed to correct
the consistency errors...also where can I find the sp_repair_allow_data_loss?
Thanks> I have a backup and would like to know the best way to proceed to correct
> the consistency errors...also where can I find the
> sp_repair_allow_data_loss?
Restoring from your last known good backup is usually the best option rather
than allowing data loss. There may be other methods depending on the
specific types of corruption and affected object types.
REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC CHECKTABLE
commands. See the Books online for details.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>I receive the following after running checktable:
> CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> 'RequestWords' (object ID 910678342).
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> I have a backup and would like to know the best way to proceed to correct
> the consistency errors...also where can I find the
> sp_repair_allow_data_loss?
> Thanks|||Not sure when my last known good is and it could take quite awhile to try and
find it...is there a way to see what data would be lost first before running
REPAIR_ALLOW_DATA_LOSS ?
"Dan Guzman" wrote:
> > I have a backup and would like to know the best way to proceed to correct
> > the consistency errors...also where can I find the
> > sp_repair_allow_data_loss?
> Restoring from your last known good backup is usually the best option rather
> than allowing data loss. There may be other methods depending on the
> specific types of corruption and affected object types.
> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC CHECKTABLE
> commands. See the Books online for details.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
> >I receive the following after running checktable:
> >
> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> > 'RequestWords' (object ID 910678342).
> > repair_allow_data_loss is the minimum repair level for the errors found by
> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >
> > I have a backup and would like to know the best way to proceed to correct
> > the consistency errors...also where can I find the
> > sp_repair_allow_data_loss?
> >
> > Thanks
>|||> Not sure when my last known good is and it could take quite awhile to try
> and
> find it...is there a way to see what data would be lost first before
> running
> REPAIR_ALLOW_DATA_LOSS ?
The DBCC CHECKTABLE output should specify the problem pages and error
details. You can use DBCC PAGE (google is your friend) to examine the page
contents and get an idea of data might be affected. I don't believe it's
possible to provide exact details of lost data beforehand; I would think
DBCC could recover the data without loss if that were possible.
You might try posting the DBCC error details in case we can provide an
alternate solution. You could also try running the DBCC CHECKTABLE WITH
REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
the problem and identify lost data.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
> Not sure when my last known good is and it could take quite awhile to try
> and
> find it...is there a way to see what data would be lost first before
> running
> REPAIR_ALLOW_DATA_LOSS ?
> "Dan Guzman" wrote:
>> > I have a backup and would like to know the best way to proceed to
>> > correct
>> > the consistency errors...also where can I find the
>> > sp_repair_allow_data_loss?
>> Restoring from your last known good backup is usually the best option
>> rather
>> than allowing data loss. There may be other methods depending on the
>> specific types of corruption and affected object types.
>> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
>> CHECKTABLE
>> commands. See the Books online for details.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>> >I receive the following after running checktable:
>> >
>> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
>> > 'RequestWords' (object ID 910678342).
>> > repair_allow_data_loss is the minimum repair level for the errors found
>> > by
>> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >
>> > I have a backup and would like to know the best way to proceed to
>> > correct
>> > the consistency errors...also where can I find the
>> > sp_repair_allow_data_loss?
>> >
>> > Thanks|||Dan, I am going to paste the following detail, the table is a simple 2 column
that is used by a full text indexing job, it seems, the first field is just
text and the second is a guid...I went to record 128, but saw nothing
funny.....appreciate all your help
Server: Msg 8928, Level 16, State 1, Line 1
Object ID 910678342, index ID 0: Page (1:369538) could not be processed. See
other errors for details.
Server: Msg 8944, Level 16, State 1, Line 1
Table error: Object ID 910678342, index ID 0, page (1:369538), row 125. Test
(ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
DBCC results for 'RequestWords'.
There are 1313272 rows in 11072 pages for object 'RequestWords'.
CHECKTABLE found 0 allocation errors and 2 consistency errors in table
'RequestWords' (object ID 910678342).
repair_allow_data_loss is the minimum repair level for the errors found by
DBCC CHECKTABLE (synergy.dbo.RequestWords ).
"Dan Guzman" wrote:
> > Not sure when my last known good is and it could take quite awhile to try
> > and
> > find it...is there a way to see what data would be lost first before
> > running
> > REPAIR_ALLOW_DATA_LOSS ?
> The DBCC CHECKTABLE output should specify the problem pages and error
> details. You can use DBCC PAGE (google is your friend) to examine the page
> contents and get an idea of data might be affected. I don't believe it's
> possible to provide exact details of lost data beforehand; I would think
> DBCC could recover the data without loss if that were possible.
> You might try posting the DBCC error details in case we can provide an
> alternate solution. You could also try running the DBCC CHECKTABLE WITH
> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
> the problem and identify lost data.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
> > Not sure when my last known good is and it could take quite awhile to try
> > and
> > find it...is there a way to see what data would be lost first before
> > running
> > REPAIR_ALLOW_DATA_LOSS ?
> >
> > "Dan Guzman" wrote:
> >
> >> > I have a backup and would like to know the best way to proceed to
> >> > correct
> >> > the consistency errors...also where can I find the
> >> > sp_repair_allow_data_loss?
> >>
> >> Restoring from your last known good backup is usually the best option
> >> rather
> >> than allowing data loss. There may be other methods depending on the
> >> specific types of corruption and affected object types.
> >>
> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
> >> CHECKTABLE
> >> commands. See the Books online for details.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
> >> >I receive the following after running checktable:
> >> >
> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> >> > 'RequestWords' (object ID 910678342).
> >> > repair_allow_data_loss is the minimum repair level for the errors found
> >> > by
> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >> >
> >> > I have a backup and would like to know the best way to proceed to
> >> > correct
> >> > the consistency errors...also where can I find the
> >> > sp_repair_allow_data_loss?
> >> >
> >> > Thanks
> >>
>|||The DBCC error indicates bad column offsets, which will prevent the problem
row from being parsed. I think DBCC will need to delete that row to remove
the error. You can probably fix the error with a normal delete command if
you can identify the key value of the problem row from the raw DBCC PAGE
output.
If you haven't already done so, you might try DBCC PAGE print option 3
(http://support.microsoft.com/kb/83065) to print the individual column
values (example below). I don't know how this will behave with bad column
offsets but I'm curious to find out, if you don't mind giving that a try.
The DBCC PAGE dump is probably the only data you'll have to salvage the
deleted row, unless you contact Microsoft PSS.
Hope this helps.
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:042EAEE7-D5C2-4847-9AF9-DFC92E3885FB@.microsoft.com...
> Dan, I am going to paste the following detail, the table is a simple 2
> column
> that is used by a full text indexing job, it seems, the first field is
> just
> text and the second is a guid...I went to record 128, but saw nothing
> funny.....appreciate all your help
> Server: Msg 8928, Level 16, State 1, Line 1
> Object ID 910678342, index ID 0: Page (1:369538) could not be processed.
> See
> other errors for details.
> Server: Msg 8944, Level 16, State 1, Line 1
> Table error: Object ID 910678342, index ID 0, page (1:369538), row 125.
> Test
> (ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
> DBCC results for 'RequestWords'.
> There are 1313272 rows in 11072 pages for object 'RequestWords'.
> CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> 'RequestWords' (object ID 910678342).
> repair_allow_data_loss is the minimum repair level for the errors found by
> DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>
>
> "Dan Guzman" wrote:
>> > Not sure when my last known good is and it could take quite awhile to
>> > try
>> > and
>> > find it...is there a way to see what data would be lost first before
>> > running
>> > REPAIR_ALLOW_DATA_LOSS ?
>> The DBCC CHECKTABLE output should specify the problem pages and error
>> details. You can use DBCC PAGE (google is your friend) to examine the
>> page
>> contents and get an idea of data might be affected. I don't believe it's
>> possible to provide exact details of lost data beforehand; I would think
>> DBCC could recover the data without loss if that were possible.
>> You might try posting the DBCC error details in case we can provide an
>> alternate solution. You could also try running the DBCC CHECKTABLE WITH
>> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
>> the problem and identify lost data.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
>> > Not sure when my last known good is and it could take quite awhile to
>> > try
>> > and
>> > find it...is there a way to see what data would be lost first before
>> > running
>> > REPAIR_ALLOW_DATA_LOSS ?
>> >
>> > "Dan Guzman" wrote:
>> >
>> >> > I have a backup and would like to know the best way to proceed to
>> >> > correct
>> >> > the consistency errors...also where can I find the
>> >> > sp_repair_allow_data_loss?
>> >>
>> >> Restoring from your last known good backup is usually the best option
>> >> rather
>> >> than allowing data loss. There may be other methods depending on the
>> >> specific types of corruption and affected object types.
>> >>
>> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
>> >> CHECKTABLE
>> >> commands. See the Books online for details.
>> >>
>> >> --
>> >> Hope this helps.
>> >>
>> >> Dan Guzman
>> >> SQL Server MVP
>> >>
>> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>> >> >I receive the following after running checktable:
>> >> >
>> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in
>> >> > table
>> >> > 'RequestWords' (object ID 910678342).
>> >> > repair_allow_data_loss is the minimum repair level for the errors
>> >> > found
>> >> > by
>> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >> >
>> >> > I have a backup and would like to know the best way to proceed to
>> >> > correct
>> >> > the consistency errors...also where can I find the
>> >> > sp_repair_allow_data_loss?
>> >> >
>> >> > Thanks
>> >>|||Dan, sorry took so long to get back...
I was able to locate the corrupt record in the referenced table...it was a
null id that had a guid assigned to it from another table...very weird...the
delete statement would not work on it....had to finally run
repair_allow_data_loss and then repair_fast. I lost 132 records but they
were all bogus references to the corruption...so it turned out all good.
Thanks for your assistance.
"Dan Guzman" wrote:
> The DBCC error indicates bad column offsets, which will prevent the problem
> row from being parsed. I think DBCC will need to delete that row to remove
> the error. You can probably fix the error with a normal delete command if
> you can identify the key value of the problem row from the raw DBCC PAGE
> output.
> If you haven't already done so, you might try DBCC PAGE print option 3
> (http://support.microsoft.com/kb/83065) to print the individual column
> values (example below). I don't know how this will behave with bad column
> offsets but I'm curious to find out, if you don't mind giving that a try.
> The DBCC PAGE dump is probably the only data you'll have to salvage the
> deleted row, unless you contact Microsoft PSS.
>
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> news:042EAEE7-D5C2-4847-9AF9-DFC92E3885FB@.microsoft.com...
> > Dan, I am going to paste the following detail, the table is a simple 2
> > column
> > that is used by a full text indexing job, it seems, the first field is
> > just
> > text and the second is a guid...I went to record 128, but saw nothing
> > funny.....appreciate all your help
> >
> > Server: Msg 8928, Level 16, State 1, Line 1
> > Object ID 910678342, index ID 0: Page (1:369538) could not be processed.
> > See
> > other errors for details.
> > Server: Msg 8944, Level 16, State 1, Line 1
> > Table error: Object ID 910678342, index ID 0, page (1:369538), row 125.
> > Test
> > (ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
> > DBCC results for 'RequestWords'.
> > There are 1313272 rows in 11072 pages for object 'RequestWords'.
> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
> > 'RequestWords' (object ID 910678342).
> > repair_allow_data_loss is the minimum repair level for the errors found by
> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >
> >
> >
> >
> > "Dan Guzman" wrote:
> >
> >> > Not sure when my last known good is and it could take quite awhile to
> >> > try
> >> > and
> >> > find it...is there a way to see what data would be lost first before
> >> > running
> >> > REPAIR_ALLOW_DATA_LOSS ?
> >>
> >> The DBCC CHECKTABLE output should specify the problem pages and error
> >> details. You can use DBCC PAGE (google is your friend) to examine the
> >> page
> >> contents and get an idea of data might be affected. I don't believe it's
> >> possible to provide exact details of lost data beforehand; I would think
> >> DBCC could recover the data without loss if that were possible.
> >>
> >> You might try posting the DBCC error details in case we can provide an
> >> alternate solution. You could also try running the DBCC CHECKTABLE WITH
> >> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to correct
> >> the problem and identify lost data.
> >>
> >> --
> >> Hope this helps.
> >>
> >> Dan Guzman
> >> SQL Server MVP
> >>
> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> >> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
> >> > Not sure when my last known good is and it could take quite awhile to
> >> > try
> >> > and
> >> > find it...is there a way to see what data would be lost first before
> >> > running
> >> > REPAIR_ALLOW_DATA_LOSS ?
> >> >
> >> > "Dan Guzman" wrote:
> >> >
> >> >> > I have a backup and would like to know the best way to proceed to
> >> >> > correct
> >> >> > the consistency errors...also where can I find the
> >> >> > sp_repair_allow_data_loss?
> >> >>
> >> >> Restoring from your last known good backup is usually the best option
> >> >> rather
> >> >> than allowing data loss. There may be other methods depending on the
> >> >> specific types of corruption and affected object types.
> >> >>
> >> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
> >> >> CHECKTABLE
> >> >> commands. See the Books online for details.
> >> >>
> >> >> --
> >> >> Hope this helps.
> >> >>
> >> >> Dan Guzman
> >> >> SQL Server MVP
> >> >>
> >> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
> >> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
> >> >> >I receive the following after running checktable:
> >> >> >
> >> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in
> >> >> > table
> >> >> > 'RequestWords' (object ID 910678342).
> >> >> > repair_allow_data_loss is the minimum repair level for the errors
> >> >> > found
> >> >> > by
> >> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
> >> >> >
> >> >> > I have a backup and would like to know the best way to proceed to
> >> >> > correct
> >> >> > the consistency errors...also where can I find the
> >> >> > sp_repair_allow_data_loss?
> >> >> >
> >> >> > Thanks
> >> >>
> >>
>|||I'm glad you were able to get your database fixed.
--
Dan Guzman
SQL Server MVP
"Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
news:8525A1AF-4A88-47B3-AA8F-1144B9814DA8@.microsoft.com...
> Dan, sorry took so long to get back...
> I was able to locate the corrupt record in the referenced table...it was
> a
> null id that had a guid assigned to it from another table...very
> weird...the
> delete statement would not work on it....had to finally run
> repair_allow_data_loss and then repair_fast. I lost 132 records but they
> were all bogus references to the corruption...so it turned out all good.
> Thanks for your assistance.
> "Dan Guzman" wrote:
>> The DBCC error indicates bad column offsets, which will prevent the
>> problem
>> row from being parsed. I think DBCC will need to delete that row to
>> remove
>> the error. You can probably fix the error with a normal delete command
>> if
>> you can identify the key value of the problem row from the raw DBCC PAGE
>> output.
>> If you haven't already done so, you might try DBCC PAGE print option 3
>> (http://support.microsoft.com/kb/83065) to print the individual column
>> values (example below). I don't know how this will behave with bad
>> column
>> offsets but I'm curious to find out, if you don't mind giving that a try.
>> The DBCC PAGE dump is probably the only data you'll have to salvage the
>> deleted row, unless you contact Microsoft PSS.
>>
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> news:042EAEE7-D5C2-4847-9AF9-DFC92E3885FB@.microsoft.com...
>> > Dan, I am going to paste the following detail, the table is a simple 2
>> > column
>> > that is used by a full text indexing job, it seems, the first field is
>> > just
>> > text and the second is a guid...I went to record 128, but saw nothing
>> > funny.....appreciate all your help
>> >
>> > Server: Msg 8928, Level 16, State 1, Line 1
>> > Object ID 910678342, index ID 0: Page (1:369538) could not be
>> > processed.
>> > See
>> > other errors for details.
>> > Server: Msg 8944, Level 16, State 1, Line 1
>> > Table error: Object ID 910678342, index ID 0, page (1:369538), row 125.
>> > Test
>> > (ColumnOffsets <= (nextRec - pRec)) failed. Values are 2088 and 43.
>> > DBCC results for 'RequestWords'.
>> > There are 1313272 rows in 11072 pages for object 'RequestWords'.
>> > CHECKTABLE found 0 allocation errors and 2 consistency errors in table
>> > 'RequestWords' (object ID 910678342).
>> > repair_allow_data_loss is the minimum repair level for the errors found
>> > by
>> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >
>> >
>> >
>> >
>> > "Dan Guzman" wrote:
>> >
>> >> > Not sure when my last known good is and it could take quite awhile
>> >> > to
>> >> > try
>> >> > and
>> >> > find it...is there a way to see what data would be lost first before
>> >> > running
>> >> > REPAIR_ALLOW_DATA_LOSS ?
>> >>
>> >> The DBCC CHECKTABLE output should specify the problem pages and error
>> >> details. You can use DBCC PAGE (google is your friend) to examine the
>> >> page
>> >> contents and get an idea of data might be affected. I don't believe
>> >> it's
>> >> possible to provide exact details of lost data beforehand; I would
>> >> think
>> >> DBCC could recover the data without loss if that were possible.
>> >>
>> >> You might try posting the DBCC error details in case we can provide an
>> >> alternate solution. You could also try running the DBCC CHECKTABLE
>> >> WITH
>> >> REPAIR_ALLOW_DATA_LOSS on a database copy to see what DBCC did to
>> >> correct
>> >> the problem and identify lost data.
>> >>
>> >> --
>> >> Hope this helps.
>> >>
>> >> Dan Guzman
>> >> SQL Server MVP
>> >>
>> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> >> news:60356673-18A9-41B8-929D-265E419590DA@.microsoft.com...
>> >> > Not sure when my last known good is and it could take quite awhile
>> >> > to
>> >> > try
>> >> > and
>> >> > find it...is there a way to see what data would be lost first before
>> >> > running
>> >> > REPAIR_ALLOW_DATA_LOSS ?
>> >> >
>> >> > "Dan Guzman" wrote:
>> >> >
>> >> >> > I have a backup and would like to know the best way to proceed to
>> >> >> > correct
>> >> >> > the consistency errors...also where can I find the
>> >> >> > sp_repair_allow_data_loss?
>> >> >>
>> >> >> Restoring from your last known good backup is usually the best
>> >> >> option
>> >> >> rather
>> >> >> than allowing data loss. There may be other methods depending on
>> >> >> the
>> >> >> specific types of corruption and affected object types.
>> >> >>
>> >> >> REPAIR_ALLOW_DATA_LOSS is an option of the DBCC CHECKDB and DBCC
>> >> >> CHECKTABLE
>> >> >> commands. See the Books online for details.
>> >> >>
>> >> >> --
>> >> >> Hope this helps.
>> >> >>
>> >> >> Dan Guzman
>> >> >> SQL Server MVP
>> >> >>
>> >> >> "Gerry M" <GerryM@.discussions.microsoft.com> wrote in message
>> >> >> news:264DC93B-200F-4567-B853-8B0DCF91852C@.microsoft.com...
>> >> >> >I receive the following after running checktable:
>> >> >> >
>> >> >> > CHECKTABLE found 0 allocation errors and 2 consistency errors in
>> >> >> > table
>> >> >> > 'RequestWords' (object ID 910678342).
>> >> >> > repair_allow_data_loss is the minimum repair level for the errors
>> >> >> > found
>> >> >> > by
>> >> >> > DBCC CHECKTABLE (synergy.dbo.RequestWords ).
>> >> >> >
>> >> >> > I have a backup and would like to know the best way to proceed to
>> >> >> > correct
>> >> >> > the consistency errors...also where can I find the
>> >> >> > sp_repair_allow_data_loss?
>> >> >> >
>> >> >> > Thanks
>> >> >>
>> >>

Friday, February 24, 2012

CHECKING the TRANSACTION LOG

I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
2000 Server. Is there a equivalent command or procedure. Thanks.
Hi Tom
Because log files are separate physical files this command is redundant. If
you want to look at the space used in the log file try DBCC SQLPERF
(logspace) http://msdn2.microsoft.com/en-us/library/aa258819(SQL.80).aspx.
For other database consistency checks DBCC CHECKDB, DBCC CHECKTABLE, DBCC
CHECKALLOC...
John
"Tom Reis" wrote:

> I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
> check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
> 2000 Server. Is there a equivalent command or procedure. Thanks.
>
>

CHECKING the TRANSACTION LOG

I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
2000 Server. Is there a equivalent command or procedure. Thanks.What is it in the transaction log that you want to check?
For 7.0 and 2000, DBCC CHECKDB and CHECKCATALOG covers integrity checks for
a database.
For 2005, you don't need CHECKCATALOG.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tom Reis" <reistom@.cdnet.cod.edu> wrote in message news:OsLvRLaCHHA.4908@.TK2MSFTNGP03.phx.g
bl...
>I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
> check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
> 2000 Server. Is there a equivalent command or procedure. Thanks.
>|||Hi Tom
Because log files are separate physical files this command is redundant. If
you want to look at the space used in the log file try DBCC SQLPERF
(logspace) http://msdn2.microsoft.com/en-us/library/aa258819(SQL.80).aspx.
For other database consistency checks DBCC CHECKDB, DBCC CHECKTABLE, DBCC
CHECKALLOC...
John
"Tom Reis" wrote:

> I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
> check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
> 2000 Server. Is there a equivalent command or procedure. Thanks.
>
>

CHECKING the TRANSACTION LOG

I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
2000 Server. Is there a equivalent command or procedure. Thanks.What is it in the transaction log that you want to check?
For 7.0 and 2000, DBCC CHECKDB and CHECKCATALOG covers integrity checks for a database.
For 2005, you don't need CHECKCATALOG.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"Tom Reis" <reistom@.cdnet.cod.edu> wrote in message news:OsLvRLaCHHA.4908@.TK2MSFTNGP03.phx.gbl...
>I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
> check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
> 2000 Server. Is there a equivalent command or procedure. Thanks.
>|||Hi Tom
Because log files are separate physical files this command is redundant. If
you want to look at the space used in the log file try DBCC SQLPERF
(logspace) http://msdn2.microsoft.com/en-us/library/aa258819(SQL.80).aspx.
For other database consistency checks DBCC CHECKDB, DBCC CHECKTABLE, DBCC
CHECKALLOC...
John
"Tom Reis" wrote:
> I am running SLQ 2000 SP4. I used to use the DBCC CHECKTABLE (syslogs) to
> check the transaction log on a SQL 6.5 server. This doesn't work on a SQL
> 2000 Server. Is there a equivalent command or procedure. Thanks.
>
>

Thursday, March 8, 2012

checktable with repair_rebuild

checktable with repair_rebuild

checktable with repair_rebuild

checktable repair_rebuild taking long time

checktable repair_rebuild taking long time

checktable repair_rebuild taking long time

checktable error

Friday, February 24, 2012

CHECKING the TRANSACTION LOG

CHECKING the TRANSACTION LOG

CHECKING the TRANSACTION LOG

check sql licence

Blog Archive

About Me