error at recbase.cpp:1378 - what now?

Hi,
We have had an SQL Server Assertion at "recbase.cpp:1378" caused by corrupt
pages in one table. We were able to recover most of our data from this table
without a restore (which would take very much time and will result in loss
of date since the last backup was done).
We still have the table (renamed) in the database and it still contains the
corrupt pages.
We know the corruption to be caused by a server crash - the hardware is ok.
My questions:
Should we drop the table? Will the pages be corrected when they are
recycled? Should we transfer the whole database without the corrupt data to
another database and dropt the whole damaged database instead (to be sure to
get rid of the corruption)? Or is this not necessary?
SvenHi Sven,
If you've recovered as much data as you're comfortable with and you're sure
you know why the corruption occured (just crashing the server should never
cause corruption) then you can go ahead and drop the table.
Regards,
Paul.
--
Paul Randal
DBCC Technical Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sven Erik Matzen" <sven.matzen@.dontspamme.com> wrote in message
news:uRd9PCikDHA.2244@.TK2MSFTNGP12.phx.gbl...
> Hi,
> We have had an SQL Server Assertion at "recbase.cpp:1378" caused by
corrupt
> pages in one table. We were able to recover most of our data from this
table
> without a restore (which would take very much time and will result in loss
> of date since the last backup was done).
> We still have the table (renamed) in the database and it still contains
the
> corrupt pages.
> We know the corruption to be caused by a server crash - the hardware is
ok.
> My questions:
> Should we drop the table? Will the pages be corrected when they are
> recycled? Should we transfer the whole database without the corrupt data
to
> another database and dropt the whole damaged database instead (to be sure
to
> get rid of the corruption)? Or is this not necessary?
> Sven
>|||Hi Paul,
Thanks for the information. I was just wondering if the "page" is corrupt or
the "data" inside the page - well, to be more specific: if there is any data
structure inside the page that is necessary to be correct when recycling the
memory for other data after dropping the table. In this case I would have
copied the data to a new database and rebuild the old from a backup of the
new one. But I'm happy not to be forced to do this - it's lot of data ;).
The appearance of the error was just after a server crash. We still do not
know exactly why the server crashed, but my admin told me that the harddisk
is ok.
Regards,
Sven
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:efu8RumkDHA.3612@.TK2MSFTNGP11.phx.gbl...
> Hi Sven,
> If you've recovered as much data as you're comfortable with and you're
sure
> you know why the corruption occured (just crashing the server should never
> cause corruption) then you can go ahead and drop the table.
> Regards,
> Paul.
> --
> Paul Randal
> DBCC Technical Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Sven Erik Matzen" <sven.matzen@.dontspamme.com> wrote in message
> news:uRd9PCikDHA.2244@.TK2MSFTNGP12.phx.gbl...
> > Hi,
> >
> > We have had an SQL Server Assertion at "recbase.cpp:1378" caused by
> corrupt
> > pages in one table. We were able to recover most of our data from this
> table
> > without a restore (which would take very much time and will result in
loss
> > of date since the last backup was done).
> > We still have the table (renamed) in the database and it still contains
> the
> > corrupt pages.
> > We know the corruption to be caused by a server crash - the hardware is
> ok.
> >
> > My questions:
> > Should we drop the table? Will the pages be corrected when they are
> > recycled? Should we transfer the whole database without the corrupt data
> to
> > another database and dropt the whole damaged database instead (to be
sure
> to
> > get rid of the corruption)? Or is this not necessary?
> >
> > Sven
> >
> >
>|||No - the page is completely reformatted when it is re-used.
By 'server crash', do you mean the physical machine rebooted/powered down or
just that SQL Server crashed and restarted? The latter should not cause
corruption - the format might depending on your hardware setup.
Regards,
Paul.
--
Paul Randal
DBCC Technical Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Sven Erik Matzen" <sven.matzen@.dontspamme.com> wrote in message
news:ugDr3VukDHA.2080@.TK2MSFTNGP10.phx.gbl...
> Hi Paul,
> Thanks for the information. I was just wondering if the "page" is corrupt
or
> the "data" inside the page - well, to be more specific: if there is any
data
> structure inside the page that is necessary to be correct when recycling
the
> memory for other data after dropping the table. In this case I would have
> copied the data to a new database and rebuild the old from a backup of the
> new one. But I'm happy not to be forced to do this - it's lot of data ;).
> The appearance of the error was just after a server crash. We still do not
> know exactly why the server crashed, but my admin told me that the
harddisk
> is ok.
> Regards,
> Sven
> "Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
> news:efu8RumkDHA.3612@.TK2MSFTNGP11.phx.gbl...
> > Hi Sven,
> >
> > If you've recovered as much data as you're comfortable with and you're
> sure
> > you know why the corruption occured (just crashing the server should
never
> > cause corruption) then you can go ahead and drop the table.
> >
> > Regards,
> >
> > Paul.
> >
> > --
> > Paul Randal
> > DBCC Technical Lead, Microsoft SQL Server Storage Engine
> >
> > This posting is provided "AS IS" with no warranties, and confers no
> rights.
> > "Sven Erik Matzen" <sven.matzen@.dontspamme.com> wrote in message
> > news:uRd9PCikDHA.2244@.TK2MSFTNGP12.phx.gbl...
> > > Hi,
> > >
> > > We have had an SQL Server Assertion at "recbase.cpp:1378" caused by
> > corrupt
> > > pages in one table. We were able to recover most of our data from this
> > table
> > > without a restore (which would take very much time and will result in
> loss
> > > of date since the last backup was done).
> > > We still have the table (renamed) in the database and it still
contains
> > the
> > > corrupt pages.
> > > We know the corruption to be caused by a server crash - the hardware
is
> > ok.
> > >
> > > My questions:
> > > Should we drop the table? Will the pages be corrected when they are
> > > recycled? Should we transfer the whole database without the corrupt
data
> > to
> > > another database and dropt the whole damaged database instead (to be
> sure
> > to
> > > get rid of the corruption)? Or is this not necessary?
> > >
> > > Sven
> > >
> > >
> >
> >
>|||Hello Paul,
The crash was a "physical" one - we are still not completely sure what was
responable for it, but it seems that there was a problem with one of its
power supply. Normally this should not be a problem (we have 3 of them per
server), but if the voltage becomes instable of one of them I can imaginge
that the mainboard or CPU will not be able to compensate this. Our
expirience was simply a black screen. The machine was not reachable via
network, it did not produce any video signal and even the remote access card
(separate nic and processor) was not responding. No entries in the
event-log. So we hope it's fixed now - I'm not sure what was done to prevent
this in the future, but I think the admins have applied some "general
improvement" because they were not able to tell me what it really was.
Again: many thanks for the information - it has saved me hours ;)
CU,
Sven
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:#rD9jd0kDHA.360@.TK2MSFTNGP12.phx.gbl...
> No - the page is completely reformatted when it is re-used.
> By 'server crash', do you mean the physical machine rebooted/powered down
or
> just that SQL Server crashed and restarted? The latter should not cause
> corruption - the format might depending on your hardware setup.
> Regards,
> Paul.
> --
> Paul Randal
> DBCC Technical Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> "Sven Erik Matzen" <sven.matzen@.dontspamme.com> wrote in message
> news:ugDr3VukDHA.2080@.TK2MSFTNGP10.phx.gbl...
> > Hi Paul,
> >
> > Thanks for the information. I was just wondering if the "page" is
corrupt
> or
> > the "data" inside the page - well, to be more specific: if there is any
> data
> > structure inside the page that is necessary to be correct when recycling
> the
> > memory for other data after dropping the table. In this case I would
have
> > copied the data to a new database and rebuild the old from a backup of
the
> > new one. But I'm happy not to be forced to do this - it's lot of data
;).
> > The appearance of the error was just after a server crash. We still do
not
> > know exactly why the server crashed, but my admin told me that the
> harddisk
> > is ok.
> >
> > Regards,
> > Sven
> >
> > "Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
> > news:efu8RumkDHA.3612@.TK2MSFTNGP11.phx.gbl...
> > > Hi Sven,
> > >
> > > If you've recovered as much data as you're comfortable with and you're
> > sure
> > > you know why the corruption occured (just crashing the server should
> never
> > > cause corruption) then you can go ahead and drop the table.
> > >
> > > Regards,
> > >
> > > Paul.
> > >
> > > --
> > > Paul Randal
> > > DBCC Technical Lead, Microsoft SQL Server Storage Engine
> > >
> > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> > > "Sven Erik Matzen" <sven.matzen@.dontspamme.com> wrote in message
> > > news:uRd9PCikDHA.2244@.TK2MSFTNGP12.phx.gbl...
> > > > Hi,
> > > >
> > > > We have had an SQL Server Assertion at "recbase.cpp:1378" caused by
> > > corrupt
> > > > pages in one table. We were able to recover most of our data from
this
> > > table
> > > > without a restore (which would take very much time and will result
in
> > loss
> > > > of date since the last backup was done).
> > > > We still have the table (renamed) in the database and it still
> contains
> > > the
> > > > corrupt pages.
> > > > We know the corruption to be caused by a server crash - the hardware
> is
> > > ok.
> > > >
> > > > My questions:
> > > > Should we drop the table? Will the pages be corrected when they are
> > > > recycled? Should we transfer the whole database without the corrupt
> data
> > > to
> > > > another database and dropt the whole damaged database instead (to be
> > sure
> > > to
> > > > get rid of the corruption)? Or is this not necessary?
> > > >
> > > > Sven
> > > >
> > > >
> > >
> > >
> >
> >
>