I/O error (torn page) detected during read at offset

Hi,
I am getting this error on running a Stored Procedure:
Server: Msg 823, Level 24, State 2, Line 1
I/O error (torn page) detected during read at offset 0x000000062b4000 in
file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
What does this error indicate and what needs to be done to resolve this
error. Thanks in advance.You have hardware or system problem perhaps.
You need to run DBCC CheckDB and look for it to report any problems...
http://support.microsoft.com/kb/828339
/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:E3E0B9C5-C826-462D-8D82-026F0F0A590E@.microsoft.com...
> Hi,
> I am getting this error on running a Stored Procedure:
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000062b4000 in
> file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
> What does this error indicate and what needs to be done to resolve this
> error. Thanks in advance.
>
>|||Here is another article to better explain torn pages and what they mean...
http://www.microsoft.com/technet/pr...ntsolutions.com
*/
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:E3E0B9C5-C826-462D-8D82-026F0F0A590E@.microsoft.com...
> Hi,
> I am getting this error on running a Stored Procedure:
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000062b4000 in
> file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
> What does this error indicate and what needs to be done to resolve this
> error. Thanks in advance.
>
>

I/O error (torn page) detected during read at offset

Hi,
I am getting this error on running a Stored Procedure:
Server: Msg 823, Level 24, State 2, Line 1
I/O error (torn page) detected during read at offset 0x000000062b4000 in
file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
What does this error indicate and what needs to be done to resolve this
error. Thanks in advance.
You have hardware or system problem perhaps.
You need to run DBCC CheckDB and look for it to report any problems...
http://support.microsoft.com/kb/828339

/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:E3E0B9C5-C826-462D-8D82-026F0F0A590E@.microsoft.com...
> Hi,
> I am getting this error on running a Stored Procedure:
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000062b4000 in
> file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
> What does this error indicate and what needs to be done to resolve this
> error. Thanks in advance.
>
>
|||Here is another article to better explain torn pages and what they mean...
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
Do a find for Torn I/O.
/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:E3E0B9C5-C826-462D-8D82-026F0F0A590E@.microsoft.com...
> Hi,
> I am getting this error on running a Stored Procedure:
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000062b4000 in
> file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
> What does this error indicate and what needs to be done to resolve this
> error. Thanks in advance.
>
>

I/O error (torn page) detected during read at offset

Hi,
I am getting this error on running a Stored Procedure:
Server: Msg 823, Level 24, State 2, Line 1
I/O error (torn page) detected during read at offset 0x000000062b4000 in
file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
What does this error indicate and what needs to be done to resolve this
error. Thanks in advance.You have hardware or system problem perhaps.
You need to run DBCC CheckDB and look for it to report any problems...
http://support.microsoft.com/kb/828339
/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:E3E0B9C5-C826-462D-8D82-026F0F0A590E@.microsoft.com...
> Hi,
> I am getting this error on running a Stored Procedure:
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000062b4000 in
> file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
> What does this error indicate and what needs to be done to resolve this
> error. Thanks in advance.
>
>|||Here is another article to better explain torn pages and what they mean...
http://www.microsoft.com/technet/prodtechnol/sql/2000/maintain/sqlIObasics.mspx
Do a find for Torn I/O.
--
/*
Warren Brunk - MCITP,MCTS,MCDBA
www.techintsolutions.com
*/
"sharman" <sharman@.discussions.microsoft.com> wrote in message
news:E3E0B9C5-C826-462D-8D82-026F0F0A590E@.microsoft.com...
> Hi,
> I am getting this error on running a Stored Procedure:
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000062b4000 in
> file 'E:\database\Microsoft SQL Server\MSSQL\Data\Mydatabase_Data.MDF'.
> What does this error indicate and what needs to be done to resolve this
> error. Thanks in advance.
>
>sql

I/O error (torn page) detected during read

we are running a maintainance plan on sql 2000 standard edition, got the error,
[2] Database db_source: Check Data Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC SQL
Server Driver][SQL Server]Object ID 1221579390, index ID 0: Page (1:197116)
could not be processed. See other errors for details.
[Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID
1221579390, index ID 0, page (1:197116).
Test (IS_ON (BUF_IOERR, bp->bstat) &&bp->berrcode) failed. Values are 2057
and -1.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
errors and 2 consistency errors in table 'xxx'(object ID 1221579390).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
errors and 2 consistency errors in database 'db_source'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is the
minimum repair level for the errors found by DBCC CHECKDB (db_source noindex).
when i run query on anlyzer select * from xxx, i got the error
Server: Msg 823, Level 24, State 2, Line 1
I/O error (torn page) detected during read at offset 0x000000603f8000 in
file 'F:\Program Files\Microsoft SQL Server\MSSQL\data\db_Data.MDF'.
Connection Broken
please help. thanks
Unless this is a nonclustered index your best bet is to restore from the
last known good backup. Do you have Torn Page Detection turned on for that
db? If not you should so you can spot issues like this sooner. In any case
have a look at this series from Paul Randal on checkdb and what your options
are.
[url]http://www.sqlskills.com/blogs/paul/CategoryView,category,CHECKDB%2BFrom%2BEvery%2BAng le.aspx[/url]
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"tulip" <tulip@.discussions.microsoft.com> wrote in message
news:DF042B2B-3DE5-455A-90C2-038534D6CEC7@.microsoft.com...
> we are running a maintainance plan on sql 2000 standard edition, got the
> error,
> [2] Database db_source: Check Data Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC
> SQL
> Server Driver][SQL Server]Object ID 1221579390, index ID 0: Page
> (1:197116)
> could not be processed. See other errors for details.
> [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID
> 1221579390, index ID 0, page (1:197116).
> Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are
> 2057
> and -1.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> errors and 2 consistency errors in table 'xxx'(object ID 1221579390).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> errors and 2 consistency errors in database 'db_source'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is
> the
> minimum repair level for the errors found by DBCC CHECKDB (db_source
> noindex).
> when i run query on anlyzer select * from xxx, i got the error
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000603f8000 in
> file 'F:\Program Files\Microsoft SQL Server\MSSQL\data\db_Data.MDF'.
> Connection Broken
> please help. thanks
>
|||i found that the error is dated back to 2006, so the backup since then won't
be valid, right?
what does this mean: repair_allow_data_loss is the minimum repair level for
the errors found by DBCC CHECKDB (db_source noindex).
thank you
"Andrew J. Kelly" wrote:

> Unless this is a nonclustered index your best bet is to restore from the
> last known good backup. Do you have Torn Page Detection turned on for that
> db? If not you should so you can spot issues like this sooner. In any case
> have a look at this series from Paul Randal on checkdb and what your options
> are.
> [url]http://www.sqlskills.com/blogs/paul/CategoryView,category,CHECKDB%2BFrom%2BEvery%2BAng le.aspx[/url]
>
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "tulip" <tulip@.discussions.microsoft.com> wrote in message
> news:DF042B2B-3DE5-455A-90C2-038534D6CEC7@.microsoft.com...
>
|||> what does this mean: repair_allow_data_loss is the minimum repair level
> for
> the errors found by DBCC CHECKDB (db_source noindex).
It means that an attempt to repair the table may result in data loss, but
the only way you can try at all, is to allow for that to happen.

I/O error (torn page) detected during read

we are running a maintainance plan on sql 2000 standard edition, got the error,
[2] Database db_source: Check Data Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC SQL
Server Driver][SQL Server]Object ID 1221579390, index ID 0: Page (1:197116)
could not be processed. See other errors for details.
[Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID
1221579390, index ID 0, page (1:197116).
Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are 2057
and -1.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
errors and 2 consistency errors in table 'xxx'(object ID 1221579390).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
errors and 2 consistency errors in database 'db_source'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is the
minimum repair level for the errors found by DBCC CHECKDB (db_source noindex).
when i run query on anlyzer select * from xxx, i got the error
Server: Msg 823, Level 24, State 2, Line 1
I/O error (torn page) detected during read at offset 0x000000603f8000 in
file 'F:\Program Files\Microsoft SQL Server\MSSQL\data\db_Data.MDF'.
Connection Broken
please help. thanksUnless this is a nonclustered index your best bet is to restore from the
last known good backup. Do you have Torn Page Detection turned on for that
db? If not you should so you can spot issues like this sooner. In any case
have a look at this series from Paul Randal on checkdb and what your options
are.
http://www.sqlskills.com/blogs/paul/CategoryView,category,CHECKDB%2BFrom%2BEvery%2BAngle.aspx
Andrew J. Kelly SQL MVP
Solid Quality Mentors
"tulip" <tulip@.discussions.microsoft.com> wrote in message
news:DF042B2B-3DE5-455A-90C2-038534D6CEC7@.microsoft.com...
> we are running a maintainance plan on sql 2000 standard edition, got the
> error,
> [2] Database db_source: Check Data Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC
> SQL
> Server Driver][SQL Server]Object ID 1221579390, index ID 0: Page
> (1:197116)
> could not be processed. See other errors for details.
> [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID
> 1221579390, index ID 0, page (1:197116).
> Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are
> 2057
> and -1.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> errors and 2 consistency errors in table 'xxx'(object ID 1221579390).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> errors and 2 consistency errors in database 'db_source'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is
> the
> minimum repair level for the errors found by DBCC CHECKDB (db_source
> noindex).
> when i run query on anlyzer select * from xxx, i got the error
> Server: Msg 823, Level 24, State 2, Line 1
> I/O error (torn page) detected during read at offset 0x000000603f8000 in
> file 'F:\Program Files\Microsoft SQL Server\MSSQL\data\db_Data.MDF'.
> Connection Broken
> please help. thanks
>|||i found that the error is dated back to 2006, so the backup since then won't
be valid, right?
what does this mean: repair_allow_data_loss is the minimum repair level for
the errors found by DBCC CHECKDB (db_source noindex).
thank you
"Andrew J. Kelly" wrote:
> Unless this is a nonclustered index your best bet is to restore from the
> last known good backup. Do you have Torn Page Detection turned on for that
> db? If not you should so you can spot issues like this sooner. In any case
> have a look at this series from Paul Randal on checkdb and what your options
> are.
> http://www.sqlskills.com/blogs/paul/CategoryView,category,CHECKDB%2BFrom%2BEvery%2BAngle.aspx
>
> --
> Andrew J. Kelly SQL MVP
> Solid Quality Mentors
>
> "tulip" <tulip@.discussions.microsoft.com> wrote in message
> news:DF042B2B-3DE5-455A-90C2-038534D6CEC7@.microsoft.com...
> > we are running a maintainance plan on sql 2000 standard edition, got the
> > error,
> >
> > [2] Database db_source: Check Data Linkage...
> > [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8928: [Microsoft][ODBC
> > SQL
> > Server Driver][SQL Server]Object ID 1221579390, index ID 0: Page
> > (1:197116)
> > could not be processed. See other errors for details.
> > [Microsoft][ODBC SQL Server Driver][SQL Server]Table error: Object ID
> > 1221579390, index ID 0, page (1:197116).
> > Test (IS_ON (BUF_IOERR, bp->bstat) && bp->berrcode) failed. Values are
> > 2057
> > and -1.
> > [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> > errors and 2 consistency errors in table 'xxx'(object ID 1221579390).
> > [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 0 allocation
> > errors and 2 consistency errors in database 'db_source'.
> > [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss is
> > the
> > minimum repair level for the errors found by DBCC CHECKDB (db_source
> > noindex).
> >
> > when i run query on anlyzer select * from xxx, i got the error
> > Server: Msg 823, Level 24, State 2, Line 1
> > I/O error (torn page) detected during read at offset 0x000000603f8000 in
> > file 'F:\Program Files\Microsoft SQL Server\MSSQL\data\db_Data.MDF'.
> >
> > Connection Broken
> >
> > please help. thanks
> >
> >
>|||> what does this mean: repair_allow_data_loss is the minimum repair level
> for
> the errors found by DBCC CHECKDB (db_source noindex).
It means that an attempt to repair the table may result in data loss, but
the only way you can try at all, is to allow for that to happen.

I/O error (torn page) #823

I have recently had a drive failure (1 of 5 in a RAID 5 config). Along with
the drive failure, removing the faulty drive resulted in a registry failure
(Windows 200 Server SP4). So after pulling my hair out all day I, finally
restore the registry file,
and get back up with 4 of 5 drives running with a replacement on it's way to
morrow.
what a day but it's over right? of course not, I'm now getting an I/O error
(torn page) error when running some select statments.
Any suggestions as to the best way of handling this? Should I wait until a
get the fifth drive back? DBCC CHECKDB WITH REPAIR_BUILD ? I don't have
a real time back-up but could if necessary back up from last week and recrea
te the current week but wha
t a pain. Can/should I export the main datafiles to txt, recreate the table
s and import back in?
any suggestions would be greatly appreciated.
thanksAs far as I know, a torn page will always be deleted by DBCC CHECKDB with an
y repair option. If it is an index
page, you are lucky, as DBCC should be able to rebuild that index. If it is
a data page, you are not so lucky.
And if it is some allocation page (like an IAM page), you are not lucky at a
ll! All this is because the page
cannot be trusted so DBCC has to not only remove the page, but also pages th
at are dependent on that page.
I suggest you start with reading the general recommendations for a corrupt
database:
http://www.karaszi.com/sqlserver/in..._suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"graham" <anonymous@.discussions.microsoft.com> wrote in message
news:90FD4BA4-D1F6-4528-9BA0-97A1E8003004@.microsoft.com...
> I have recently had a drive failure (1 of 5 in a RAID 5 config). Along with the d
rive failure, removing the
faulty drive resulted in a registry failure (Windows 200 Server SP4). So af
ter pulling my hair out all day I,
finally restore the registry file, and get back up with 4 of 5 drives runnin
g with a replacement on it's way
tomorrow.
> what a day but it's over right? of course not, I'm now getting an I/O error (torn
page) error when running
some select statments.
> Any suggestions as to the best way of handling this? Should I wait until a get th
e fifth drive back? DBCC
CHECKDB WITH REPAIR_BUILD ? I don't have a real time back-up but could if
necessary back up from last week
and recreate the current week but what a pain. Can/should I export the main
datafiles to txt, recreate the
tables and import back in?
> any suggestions would be greatly appreciated.
> thanks|||No - torn page in non-clustered indexes will be deleted when the index is
rebuilt under any of the repair options. Any other kind of torn page can
only be fixed with REPAIR_ALLOW_DATA_LOSS.
You should move to new hardware and restore from a backup before considering
running repair (as your last resort).
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OHrU9DxFEHA.2976@.TK2MSFTNGP10.phx.gbl...
> As far as I know, a torn page will always be deleted by DBCC CHECKDB with
any repair option. If it is an index
> page, you are lucky, as DBCC should be able to rebuild that index. If it
is a data page, you are not so lucky.
> And if it is some allocation page (like an IAM page), you are not lucky at
all! All this is because the page
> cannot be trusted so DBCC has to not only remove the page, but also pages
that are dependent on that page.
> I suggest you start with reading the general recommendations for a
corrupt database:
> http://www.karaszi.com/sqlserver/in..._suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "graham" <anonymous@.discussions.microsoft.com> wrote in message
> news:90FD4BA4-D1F6-4528-9BA0-97A1E8003004@.microsoft.com...
with the drive failure, removing the
> faulty drive resulted in a registry failure (Windows 200 Server SP4). So
after pulling my hair out all day I,
> finally restore the registry file, and get back up with 4 of 5 drives
running with a replacement on it's way
> tomorrow.
error (torn page) error when running
> some select statments.
until a get the fifth drive back? DBCC
> CHECKDB WITH REPAIR_BUILD ? I don't have a real time back-up but could
if necessary back up from last week
> and recreate the current week but what a pain. Can/should I export the
main datafiles to txt, recreate the
> tables and import back in?
>|||Thanks for catching my mind-slip, Paul.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:OBsovo1FEHA.3540@.TK2MSFTNGP09.phx.gbl...
> No - torn page in non-clustered indexes will be deleted when the index is
> rebuilt under any of the repair options. Any other kind of torn page can
> only be fixed with REPAIR_ALLOW_DATA_LOSS.
> You should move to new hardware and restore from a backup before consideri
ng
> running repair (as your last resort).
> Regards.
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights
.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote i
n
> message news:OHrU9DxFEHA.2976@.TK2MSFTNGP10.phx.gbl...
> any repair option. If it is an index
> is a data page, you are not so lucky.
> all! All this is because the page
> that are dependent on that page.
> corrupt database:
> with the drive failure, removing the
> after pulling my hair out all day I,
> running with a replacement on it's way
> error (torn page) error when running
> until a get the fifth drive back? DBCC
> if necessary back up from last week
> main datafiles to txt, recreate the
>

I/O error (torn page) #823

I have recently had a drive failure (1 of 5 in a RAID 5 config). Along with the drive failure, removing the faulty drive resulted in a registry failure (Windows 200 Server SP4). So after pulling my hair out all day I, finally restore the registry file,
and get back up with 4 of 5 drives running with a replacement on it's way tomorrow.
what a day but it's over right? of course not, I'm now getting an I/O error (torn page) error when running some select statments.
Any suggestions as to the best way of handling this? Should I wait until a get the fifth drive back? DBCC CHECKDB WITH REPAIR_BUILD ? I don't have a real time back-up but could if necessary back up from last week and recreate the current week but wha
t a pain. Can/should I export the main datafiles to txt, recreate the tables and import back in?
any suggestions would be greatly appreciated.
thanks
As far as I know, a torn page will always be deleted by DBCC CHECKDB with any repair option. If it is an index
page, you are lucky, as DBCC should be able to rebuild that index. If it is a data page, you are not so lucky.
And if it is some allocation page (like an IAM page), you are not lucky at all! All this is because the page
cannot be trusted so DBCC has to not only remove the page, but also pages that are dependent on that page.
I suggest you start with reading the general recommendations for a corrupt database:
http://www.karaszi.com/sqlserver/inf...suspect_db.asp
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"graham" <anonymous@.discussions.microsoft.com> wrote in message
news:90FD4BA4-D1F6-4528-9BA0-97A1E8003004@.microsoft.com...
> I have recently had a drive failure (1 of 5 in a RAID 5 config). Along with the drive failure, removing the
faulty drive resulted in a registry failure (Windows 200 Server SP4). So after pulling my hair out all day I,
finally restore the registry file, and get back up with 4 of 5 drives running with a replacement on it's way
tomorrow.
> what a day but it's over right? of course not, I'm now getting an I/O error (torn page) error when running
some select statments.
> Any suggestions as to the best way of handling this? Should I wait until a get the fifth drive back? DBCC
CHECKDB WITH REPAIR_BUILD ? I don't have a real time back-up but could if necessary back up from last week
and recreate the current week but what a pain. Can/should I export the main datafiles to txt, recreate the
tables and import back in?
> any suggestions would be greatly appreciated.
> thanks
|||No - torn page in non-clustered indexes will be deleted when the index is
rebuilt under any of the repair options. Any other kind of torn page can
only be fixed with REPAIR_ALLOW_DATA_LOSS.
You should move to new hardware and restore from a backup before considering
running repair (as your last resort).
Regards.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
message news:OHrU9DxFEHA.2976@.TK2MSFTNGP10.phx.gbl...
> As far as I know, a torn page will always be deleted by DBCC CHECKDB with
any repair option. If it is an index
> page, you are lucky, as DBCC should be able to rebuild that index. If it
is a data page, you are not so lucky.
> And if it is some allocation page (like an IAM page), you are not lucky at
all! All this is because the page
> cannot be trusted so DBCC has to not only remove the page, but also pages
that are dependent on that page.
> I suggest you start with reading the general recommendations for a
corrupt database:
> http://www.karaszi.com/sqlserver/inf...suspect_db.asp
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
>
> "graham" <anonymous@.discussions.microsoft.com> wrote in message
> news:90FD4BA4-D1F6-4528-9BA0-97A1E8003004@.microsoft.com...
with the drive failure, removing the
> faulty drive resulted in a registry failure (Windows 200 Server SP4). So
after pulling my hair out all day I,
> finally restore the registry file, and get back up with 4 of 5 drives
running with a replacement on it's way
> tomorrow.
error (torn page) error when running
> some select statments.
until a get the fifth drive back? DBCC
> CHECKDB WITH REPAIR_BUILD ? I don't have a real time back-up but could
if necessary back up from last week
> and recreate the current week but what a pain. Can/should I export the
main datafiles to txt, recreate the
> tables and import back in?
>
|||Thanks for catching my mind-slip, Paul.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
"Paul S Randal [MS]" <prandal@.online.microsoft.com> wrote in message
news:OBsovo1FEHA.3540@.TK2MSFTNGP09.phx.gbl...
> No - torn page in non-clustered indexes will be deleted when the index is
> rebuilt under any of the repair options. Any other kind of torn page can
> only be fixed with REPAIR_ALLOW_DATA_LOSS.
> You should move to new hardware and restore from a backup before considering
> running repair (as your last resort).
> Regards.
> --
> Paul Randal
> Dev Lead, Microsoft SQL Server Storage Engine
> This posting is provided "AS IS" with no warranties, and confers no rights.
> "Tibor Karaszi" <tibor_please.no.email_karaszi@.hotmail.nomail.com> wrote in
> message news:OHrU9DxFEHA.2976@.TK2MSFTNGP10.phx.gbl...
> any repair option. If it is an index
> is a data page, you are not so lucky.
> all! All this is because the page
> that are dependent on that page.
> corrupt database:
> with the drive failure, removing the
> after pulling my hair out all day I,
> running with a replacement on it's way
> error (torn page) error when running
> until a get the fifth drive back? DBCC
> if necessary back up from last week
> main datafiles to txt, recreate the
>

I/O error (Torn page)

I run a sp in sqlserver 2000 and got this error message.
(1 row affected)
Msg 823, Level 24, State 2, Server DBINT02, Procedure
KundAvpris_Insert, Line 13
I/O error (torn page) detected during read at offset
0x0000013a29a000 in file
'E:\Program Files\Microsoft SQL
Server\MSSQL\data\MARKISDATA_Data.MDF'.
Does anybody know how i do to correct this error?I suggest you perform a log backup. Then restore the latest clean database backup and all subsequent
log backups (including this last one). This will most probably give you zero data loss.
If you don't have log backups in place, then just go for the last clean database backups.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Robert Johansson" <rbjoh@.wmdata.com> wrote in message
news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> I run a sp in sqlserver 2000 and got this error message.
> (1 row affected)
> Msg 823, Level 24, State 2, Server DBINT02, Procedure
> KundAvpris_Insert, Line 13
> I/O error (torn page) detected during read at offset
> 0x0000013a29a000 in file
> 'E:\Program Files\Microsoft SQL
> Server\MSSQL\data\MARKISDATA_Data.MDF'.
> Does anybody know how i do to correct this error?|||Robert
Ask your system
administrator to check for disk corruption.You should make sure to run DBCC
CHECKDB or DBCC CHECKTABLE on that table.
"Robert Johansson" <rbjoh@.wmdata.com> wrote in message
news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> I run a sp in sqlserver 2000 and got this error message.
> (1 row affected)
> Msg 823, Level 24, State 2, Server DBINT02, Procedure
> KundAvpris_Insert, Line 13
> I/O error (torn page) detected during read at offset
> 0x0000013a29a000 in file
> 'E:\Program Files\Microsoft SQL
> Server\MSSQL\data\MARKISDATA_Data.MDF'.
> Does anybody know how i do to correct this error?|||Torn pages does most likely occur because a partially performed write operation. CHECKDB or
CHECKTABLE does not help here, as it will only confirm what we already know: a corruption in the
database. Also, this does, unfortunately, temp some to try the repair options (which in most cases
doesn't help), and possibly hinder the ability to do the vital last log backups.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Uri Dimant" <urid@.iscar.co.il> wrote in message news:uhUFzm4dDHA.2340@.TK2MSFTNGP09.phx.gbl...
> Robert
> Ask your system
> administrator to check for disk corruption.You should make sure to run DBCC
> CHECKDB or DBCC CHECKTABLE on that table.
> "Robert Johansson" <rbjoh@.wmdata.com> wrote in message
> news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> > I run a sp in sqlserver 2000 and got this error message.
> >
> > (1 row affected)
> > Msg 823, Level 24, State 2, Server DBINT02, Procedure
> > KundAvpris_Insert, Line 13
> > I/O error (torn page) detected during read at offset
> > 0x0000013a29a000 in file
> > 'E:\Program Files\Microsoft SQL
> > Server\MSSQL\data\MARKISDATA_Data.MDF'.
> >
> > Does anybody know how i do to correct this error?
>|||That might not all be necessary. If the torn page is in a non-clustered
index you can just rebuild the index and everything will be fine. If it is
in a clustered index or it is a page that is used by SQL Server internally,
Tibor's method is the safest way to go.
DBCC CHECKDB will tell you in which object the torn page is located. You can
run DBCC CHECKDB with the WITH PHYSICAL_ONLY option to speed up the process,
which can otherwise take a long time.
--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:OuN3Hl4dDHA.3592@.tk2msftngp13.phx.gbl...
> I suggest you perform a log backup. Then restore the latest clean database
backup and all subsequent
> log backups (including this last one). This will most probably give you
zero data loss.
> If you don't have log backups in place, then just go for the last clean
database backups.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at: http://groups.google.com/groups?oi=djq&as
ugroup=microsoft.public.sqlserver
>
> "Robert Johansson" <rbjoh@.wmdata.com> wrote in message
> news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> > I run a sp in sqlserver 2000 and got this error message.
> >
> > (1 row affected)
> > Msg 823, Level 24, State 2, Server DBINT02, Procedure
> > KundAvpris_Insert, Line 13
> > I/O error (torn page) detected during read at offset
> > 0x0000013a29a000 in file
> > 'E:\Program Files\Microsoft SQL
> > Server\MSSQL\data\MARKISDATA_Data.MDF'.
> >
> > Does anybody know how i do to correct this error?
>|||> That might not all be necessary. If the torn page is in a non-clustered
> index you can just rebuild the index and everything will be fine.
Does above apply to torn pages as well?
I thought that torn pages are "corrupted beyond repair", even if a page can, technically, be dropped
as part of an index...
I.e., a torn page marks a "hands off - something is fishy here" to SQL Server.
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
news:%23q9BDv4dDHA.3660@.TK2MSFTNGP11.phx.gbl...
> That might not all be necessary. If the torn page is in a non-clustered
> index you can just rebuild the index and everything will be fine. If it is
> in a clustered index or it is a page that is used by SQL Server internally,
> Tibor's method is the safest way to go.
> DBCC CHECKDB will tell you in which object the torn page is located. You can
> run DBCC CHECKDB with the WITH PHYSICAL_ONLY option to speed up the process,
> which can otherwise take a long time.
> --
> Jacco Schalkwijk MCDBA, MCSD, MCSE
> Database Administrator
> Eurostop Ltd.
>
> "Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> wrote in message news:OuN3Hl4dDHA.3592@.tk2msftngp13.phx.gbl...
> > I suggest you perform a log backup. Then restore the latest clean database
> backup and all subsequent
> > log backups (including this last one). This will most probably give you
> zero data loss.
> >
> > If you don't have log backups in place, then just go for the last clean
> database backups.
> > --
> > Tibor Karaszi, SQL Server MVP
> > Archive at: http://groups.google.com/groups?oi=djq&as
> ugroup=microsoft.public.sqlserver
> >
> >
> > "Robert Johansson" <rbjoh@.wmdata.com> wrote in message
> > news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> > > I run a sp in sqlserver 2000 and got this error message.
> > >
> > > (1 row affected)
> > > Msg 823, Level 24, State 2, Server DBINT02, Procedure
> > > KundAvpris_Insert, Line 13
> > > I/O error (torn page) detected during read at offset
> > > 0x0000013a29a000 in file
> > > 'E:\Program Files\Microsoft SQL
> > > Server\MSSQL\data\MARKISDATA_Data.MDF'.
> > >
> > > Does anybody know how i do to correct this error?
> >
> >
>|||Only thing a torn page tells you as far as I understand it, is that it was
written to disk partially but not completely, i.e. the check bits for all
the 512 byte sectors is the page are not the same, which means that some of
the sectors have changed the last time the page was written and some
haven't. It's a "logical" rather than a physical error, it doesn't tell you
anything about the current physical state of the page only about the current
logical state of the page (inconsistent) and that the last write operation
on that page didn't succeed completely. The page being torn in itself
doesn't make the harddisk space where it is located unusable. (The torn page
can ofcourse be caused by a harddisk problem which makes the disk space
unusable, but that's a separate issue.)
If the torn page has been cause by a power failure or a similar problem,
that is not a permanent hardware problem, like a bad sector on a disk, I see
no reason why you could not reuse the page?
--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:ugzTOx4dDHA.3356@.TK2MSFTNGP09.phx.gbl...
> > That might not all be necessary. If the torn page is in a non-clustered
> > index you can just rebuild the index and everything will be fine.
> Does above apply to torn pages as well?
> I thought that torn pages are "corrupted beyond repair", even if a page
can, technically, be dropped
> as part of an index...
> I.e., a torn page marks a "hands off - something is fishy here" to SQL
Server.
> --
> Tibor Karaszi, SQL Server MVP
> Archive at: http://groups.google.com/groups?oi=djq&as
ugroup=microsoft.public.sqlserver
>
> "Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
> news:%23q9BDv4dDHA.3660@.TK2MSFTNGP11.phx.gbl...
> > That might not all be necessary. If the torn page is in a non-clustered
> > index you can just rebuild the index and everything will be fine. If it
is
> > in a clustered index or it is a page that is used by SQL Server
internally,
> > Tibor's method is the safest way to go.
> >
> > DBCC CHECKDB will tell you in which object the torn page is located. You
can
> > run DBCC CHECKDB with the WITH PHYSICAL_ONLY option to speed up the
process,
> > which can otherwise take a long time.
> >
> > --
> > Jacco Schalkwijk MCDBA, MCSD, MCSE
> > Database Administrator
> > Eurostop Ltd.
> >
> >
> > "Tibor Karaszi"
<tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> > wrote in message news:OuN3Hl4dDHA.3592@.tk2msftngp13.phx.gbl...
> > > I suggest you perform a log backup. Then restore the latest clean
database
> > backup and all subsequent
> > > log backups (including this last one). This will most probably give
you
> > zero data loss.
> > >
> > > If you don't have log backups in place, then just go for the last
clean
> > database backups.
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > Archive at: http://groups.google.com/groups?oi=djq&as
> > ugroup=microsoft.public.sqlserver
> > >
> > >
> > > "Robert Johansson" <rbjoh@.wmdata.com> wrote in message
> > > news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> > > > I run a sp in sqlserver 2000 and got this error message.
> > > >
> > > > (1 row affected)
> > > > Msg 823, Level 24, State 2, Server DBINT02, Procedure
> > > > KundAvpris_Insert, Line 13
> > > > I/O error (torn page) detected during read at offset
> > > > 0x0000013a29a000 in file
> > > > 'E:\Program Files\Microsoft SQL
> > > > Server\MSSQL\data\MARKISDATA_Data.MDF'.
> > > >
> > > > Does anybody know how i do to correct this error?
> > >
> > >
> >
> >
>|||I agree, Jacco. My point as only the SQL Server code (design of-). Whether SQL Server will never
re-uses/repairs a torn page or not, even though it can safely drop the page (because the HW might be
OK). I guess the answer is inside the SQL Server code, which I don't have access to... ;-)
--
Tibor Karaszi, SQL Server MVP
Archive at: http://groups.google.com/groups?oi=djq&as ugroup=microsoft.public.sqlserver
"Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
news:%23Bj5HQ5dDHA.1044@.TK2MSFTNGP10.phx.gbl...
> Only thing a torn page tells you as far as I understand it, is that it was
> written to disk partially but not completely, i.e. the check bits for all
> the 512 byte sectors is the page are not the same, which means that some of
> the sectors have changed the last time the page was written and some
> haven't. It's a "logical" rather than a physical error, it doesn't tell you
> anything about the current physical state of the page only about the current
> logical state of the page (inconsistent) and that the last write operation
> on that page didn't succeed completely. The page being torn in itself
> doesn't make the harddisk space where it is located unusable. (The torn page
> can ofcourse be caused by a harddisk problem which makes the disk space
> unusable, but that's a separate issue.)
> If the torn page has been cause by a power failure or a similar problem,
> that is not a permanent hardware problem, like a bad sector on a disk, I see
> no reason why you could not reuse the page?
> --
> Jacco Schalkwijk MCDBA, MCSD, MCSE
> Database Administrator
> Eurostop Ltd.
>
> "Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> wrote in message news:ugzTOx4dDHA.3356@.TK2MSFTNGP09.phx.gbl...
> > > That might not all be necessary. If the torn page is in a non-clustered
> > > index you can just rebuild the index and everything will be fine.
> >
> > Does above apply to torn pages as well?
> > I thought that torn pages are "corrupted beyond repair", even if a page
> can, technically, be dropped
> > as part of an index...
> > I.e., a torn page marks a "hands off - something is fishy here" to SQL
> Server.
> >
> > --
> > Tibor Karaszi, SQL Server MVP
> > Archive at: http://groups.google.com/groups?oi=djq&as
> ugroup=microsoft.public.sqlserver
> >
> >
> > "Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
> > news:%23q9BDv4dDHA.3660@.TK2MSFTNGP11.phx.gbl...
> > > That might not all be necessary. If the torn page is in a non-clustered
> > > index you can just rebuild the index and everything will be fine. If it
> is
> > > in a clustered index or it is a page that is used by SQL Server
> internally,
> > > Tibor's method is the safest way to go.
> > >
> > > DBCC CHECKDB will tell you in which object the torn page is located. You
> can
> > > run DBCC CHECKDB with the WITH PHYSICAL_ONLY option to speed up the
> process,
> > > which can otherwise take a long time.
> > >
> > > --
> > > Jacco Schalkwijk MCDBA, MCSD, MCSE
> > > Database Administrator
> > > Eurostop Ltd.
> > >
> > >
> > > "Tibor Karaszi"
> <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> > > wrote in message news:OuN3Hl4dDHA.3592@.tk2msftngp13.phx.gbl...
> > > > I suggest you perform a log backup. Then restore the latest clean
> database
> > > backup and all subsequent
> > > > log backups (including this last one). This will most probably give
> you
> > > zero data loss.
> > > >
> > > > If you don't have log backups in place, then just go for the last
> clean
> > > database backups.
> > > > --
> > > > Tibor Karaszi, SQL Server MVP
> > > > Archive at: http://groups.google.com/groups?oi=djq&as
> > > ugroup=microsoft.public.sqlserver
> > > >
> > > >
> > > > "Robert Johansson" <rbjoh@.wmdata.com> wrote in message
> > > > news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> > > > > I run a sp in sqlserver 2000 and got this error message.
> > > > >
> > > > > (1 row affected)
> > > > > Msg 823, Level 24, State 2, Server DBINT02, Procedure
> > > > > KundAvpris_Insert, Line 13
> > > > > I/O error (torn page) detected during read at offset
> > > > > 0x0000013a29a000 in file
> > > > > 'E:\Program Files\Microsoft SQL
> > > > > Server\MSSQL\data\MARKISDATA_Data.MDF'.
> > > > >
> > > > > Does anybody know how i do to correct this error?
> > > >
> > > >
> > >
> > >
> >
> >
>|||Sorry Tibor, your post is not really clear to me...
I don't think that you can't drop an index because it contains a torn page,
if that is what you mean? (Too bad the problem is quite difficult to
replicate). Dropping an index only deallocates the index pages and deletes
the rows from the system tables and doesn't do anything to the actual pages,
so whether they are torn or not should not make any difference.
> I guess the answer is inside the SQL Server code, which I don't have
access to... ;-)
But you have access to people who have access (or at least have access to
people who have access) ;-)
--
Jacco Schalkwijk MCDBA, MCSD, MCSE
Database Administrator
Eurostop Ltd.
"Tibor Karaszi" <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
wrote in message news:eyZU7n5dDHA.1448@.TK2MSFTNGP12.phx.gbl...
> I agree, Jacco. My point as only the SQL Server code (design of-). Whether
SQL Server will never
> re-uses/repairs a torn page or not, even though it can safely drop the
page (because the HW might be
> OK). I guess the answer is inside the SQL Server code, which I don't have
access to... ;-)
> --
> Tibor Karaszi, SQL Server MVP
> Archive at: http://groups.google.com/groups?oi=djq&as
ugroup=microsoft.public.sqlserver
>
> "Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
> news:%23Bj5HQ5dDHA.1044@.TK2MSFTNGP10.phx.gbl...
> > Only thing a torn page tells you as far as I understand it, is that it
was
> > written to disk partially but not completely, i.e. the check bits for
all
> > the 512 byte sectors is the page are not the same, which means that some
of
> > the sectors have changed the last time the page was written and some
> > haven't. It's a "logical" rather than a physical error, it doesn't tell
you
> > anything about the current physical state of the page only about the
current
> > logical state of the page (inconsistent) and that the last write
operation
> > on that page didn't succeed completely. The page being torn in itself
> > doesn't make the harddisk space where it is located unusable. (The torn
page
> > can ofcourse be caused by a harddisk problem which makes the disk space
> > unusable, but that's a separate issue.)
> >
> > If the torn page has been cause by a power failure or a similar problem,
> > that is not a permanent hardware problem, like a bad sector on a disk, I
see
> > no reason why you could not reuse the page?
> >
> > --
> > Jacco Schalkwijk MCDBA, MCSD, MCSE
> > Database Administrator
> > Eurostop Ltd.
> >
> >
> > "Tibor Karaszi"
<tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> > wrote in message news:ugzTOx4dDHA.3356@.TK2MSFTNGP09.phx.gbl...
> > > > That might not all be necessary. If the torn page is in a
non-clustered
> > > > index you can just rebuild the index and everything will be fine.
> > >
> > > Does above apply to torn pages as well?
> > > I thought that torn pages are "corrupted beyond repair", even if a
page
> > can, technically, be dropped
> > > as part of an index...
> > > I.e., a torn page marks a "hands off - something is fishy here" to SQL
> > Server.
> > >
> > > --
> > > Tibor Karaszi, SQL Server MVP
> > > Archive at: http://groups.google.com/groups?oi=djq&as
> > ugroup=microsoft.public.sqlserver
> > >
> > >
> > > "Jacco Schalkwijk" <NOSPAMjaccos@.eurostop.co.uk> wrote in message
> > > news:%23q9BDv4dDHA.3660@.TK2MSFTNGP11.phx.gbl...
> > > > That might not all be necessary. If the torn page is in a
non-clustered
> > > > index you can just rebuild the index and everything will be fine. If
it
> > is
> > > > in a clustered index or it is a page that is used by SQL Server
> > internally,
> > > > Tibor's method is the safest way to go.
> > > >
> > > > DBCC CHECKDB will tell you in which object the torn page is located.
You
> > can
> > > > run DBCC CHECKDB with the WITH PHYSICAL_ONLY option to speed up the
> > process,
> > > > which can otherwise take a long time.
> > > >
> > > > --
> > > > Jacco Schalkwijk MCDBA, MCSD, MCSE
> > > > Database Administrator
> > > > Eurostop Ltd.
> > > >
> > > >
> > > > "Tibor Karaszi"
> > <tibor.please_reply_to_public_forum.karaszi@.cornerstone.se>
> > > > wrote in message news:OuN3Hl4dDHA.3592@.tk2msftngp13.phx.gbl...
> > > > > I suggest you perform a log backup. Then restore the latest clean
> > database
> > > > backup and all subsequent
> > > > > log backups (including this last one). This will most probably
give
> > you
> > > > zero data loss.
> > > > >
> > > > > If you don't have log backups in place, then just go for the last
> > clean
> > > > database backups.
> > > > > --
> > > > > Tibor Karaszi, SQL Server MVP
> > > > > Archive at: http://groups.google.com/groups?oi=djq&as
> > > > ugroup=microsoft.public.sqlserver
> > > > >
> > > > >
> > > > > "Robert Johansson" <rbjoh@.wmdata.com> wrote in message
> > > > > news:60f401c37788$1cbdbc40$a501280a@.phx.gbl...
> > > > > > I run a sp in sqlserver 2000 and got this error message.
> > > > > >
> > > > > > (1 row affected)
> > > > > > Msg 823, Level 24, State 2, Server DBINT02, Procedure
> > > > > > KundAvpris_Insert, Line 13
> > > > > > I/O error (torn page) detected during read at offset
> > > > > > 0x0000013a29a000 in file
> > > > > > 'E:\Program Files\Microsoft SQL
> > > > > > Server\MSSQL\data\MARKISDATA_Data.MDF'.
> > > > > >
> > > > > > Does anybody know how i do to correct this error?
> > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>sql