I have setup a database maintenance plan that consistently fails when
attempting to check the integrity of my database. I have tried running
the maintenance plan switching the include/exclude indexes options,
without any difference to the result. The logging report for the
failing integrity step of the maintenance plan includes the following:
========================================
===========================
Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
Server 'myServer' as 'myServer\myUserName' (trusted)
Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:23 AM
[1] Database myDataBase: Check Data Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424)
in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data
_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
The following errors were found:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424)
in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data
_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
** Execution Time: 0 hrs, 0 mins, 8 secs **
Deleting old text reports... 1 file(s) deleted.
End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:31 AM
SQLMAINT.EXE Process Exit Code: 1 (Failed)
========================================
===========================
From this I assume that "Extent (1:357424) in database ID 7 is
allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
What does this mean and how do I resolve the problem?
Thanks,
StephenStephen,
Check the article at
serr_2_8ape.asp." target="_blank">http://msdn.microsoft.com/library/d...err_2_8ape.asp.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Stephen Miller" <jsausten@.hotmail.com> wrote in message
news:cdb404de.0408251803.4bd6cfdd@.posting.google.com...
> I have setup a database maintenance plan that consistently fails when
> attempting to check the integrity of my database. I have tried running
> the maintenance plan switching the include/exclude indexes options,
> without any difference to the result. The logging report for the
> failing integrity step of the maintenance plan includes the following:
> ========================================
===========================
> Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
> Server 'myServer' as 'myServer\myUserName' (trusted)
> Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:23 AM
> [1] Database myDataBase: Check Data Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:35742
4) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_da
ta_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> The following errors were found:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:35742
4) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_da
ta_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> ** Execution Time: 0 hrs, 0 mins, 8 secs **
> Deleting old text reports... 1 file(s) deleted.
> End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:31 AM
> SQLMAINT.EXE Process Exit Code: 1 (Failed)
> ========================================
===========================
>
> From this I assume that "Extent (1:357424) in database ID 7 is
> allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
> What does this mean and how do I resolve the problem?
> Thanks,
> Stephen|||Stephen,
If you enounter corruption related error messages the avenue most often
suggested is to restore from a known good backup. If for some reason this
is not available to you I would suggest contacting Microsoft SQL Server
Support to discuss your options and the possible implications of running
dbcc with the repair allow data loss option. Running this has some
significant risks and you may have other options.
http://support.microsoft.com/defaul...doffer41a&sd=GN
Thanks,
David Gerard
Microsoft SQL Server Supportsql
Showing posts with label setup. Show all posts
Showing posts with label setup. Show all posts
Monday, March 26, 2012
How do I interpret results from a failed integrity test?
I have setup a database maintenance plan that consistently fails when
attempting to check the integrity of my database. I have tried running
the maintenance plan switching the include/exclude indexes options,
without any difference to the result. The logging report for the
failing integrity step of the maintenance plan includes the following:
================================================== =================
Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
Server 'myServer' as 'myServer\myUserName' (trusted)
Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:23 AM
[1] Database myDataBase: Check Data Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
The following errors were found:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
** Execution Time: 0 hrs, 0 mins, 8 secs **
Deleting old text reports... 1 file(s) deleted.
End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:31 AM
SQLMAINT.EXE Process Exit Code: 1 (Failed)
================================================== =================
From this I assume that "Extent (1:357424) in database ID 7 is
allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
What does this mean and how do I resolve the problem?
Thanks,
Stephen
Stephen,
Check the article at
http://msdn.microsoft.com/library/de...rr_2_8ape.asp.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Stephen Miller" <jsausten@.hotmail.com> wrote in message
news:cdb404de.0408251803.4bd6cfdd@.posting.google.c om...
> I have setup a database maintenance plan that consistently fails when
> attempting to check the integrity of my database. I have tried running
> the maintenance plan switching the include/exclude indexes options,
> without any difference to the result. The logging report for the
> failing integrity step of the maintenance plan includes the following:
> ================================================== =================
> Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
> Server 'myServer' as 'myServer\myUserName' (trusted)
> Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:23 AM
> [1] Database myDataBase: Check Data Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> The following errors were found:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> ** Execution Time: 0 hrs, 0 mins, 8 secs **
> Deleting old text reports... 1 file(s) deleted.
> End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:31 AM
> SQLMAINT.EXE Process Exit Code: 1 (Failed)
> ================================================== =================
>
> From this I assume that "Extent (1:357424) in database ID 7 is
> allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
> What does this mean and how do I resolve the problem?
> Thanks,
> Stephen
|||Stephen,
If you enounter corruption related error messages the avenue most often
suggested is to restore from a known good backup. If for some reason this
is not available to you I would suggest contacting Microsoft SQL Server
Support to discuss your options and the possible implications of running
dbcc with the repair allow data loss option. Running this has some
significant risks and you may have other options.
http://support.microsoft.com/default...offer41a&sd=GN
Thanks,
David Gerard
Microsoft SQL Server Support
attempting to check the integrity of my database. I have tried running
the maintenance plan switching the include/exclude indexes options,
without any difference to the result. The logging report for the
failing integrity step of the maintenance plan includes the following:
================================================== =================
Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
Server 'myServer' as 'myServer\myUserName' (trusted)
Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:23 AM
[1] Database myDataBase: Check Data Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
The following errors were found:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
** Execution Time: 0 hrs, 0 mins, 8 secs **
Deleting old text reports... 1 file(s) deleted.
End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:31 AM
SQLMAINT.EXE Process Exit Code: 1 (Failed)
================================================== =================
From this I assume that "Extent (1:357424) in database ID 7 is
allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
What does this mean and how do I resolve the problem?
Thanks,
Stephen
Stephen,
Check the article at
http://msdn.microsoft.com/library/de...rr_2_8ape.asp.
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Stephen Miller" <jsausten@.hotmail.com> wrote in message
news:cdb404de.0408251803.4bd6cfdd@.posting.google.c om...
> I have setup a database maintenance plan that consistently fails when
> attempting to check the integrity of my database. I have tried running
> the maintenance plan switching the include/exclude indexes options,
> without any difference to the result. The logging report for the
> failing integrity step of the maintenance plan includes the following:
> ================================================== =================
> Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
> Server 'myServer' as 'myServer\myUserName' (trusted)
> Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:23 AM
> [1] Database myDataBase: Check Data Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> The following errors were found:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> ** Execution Time: 0 hrs, 0 mins, 8 secs **
> Deleting old text reports... 1 file(s) deleted.
> End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:31 AM
> SQLMAINT.EXE Process Exit Code: 1 (Failed)
> ================================================== =================
>
> From this I assume that "Extent (1:357424) in database ID 7 is
> allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
> What does this mean and how do I resolve the problem?
> Thanks,
> Stephen
|||Stephen,
If you enounter corruption related error messages the avenue most often
suggested is to restore from a known good backup. If for some reason this
is not available to you I would suggest contacting Microsoft SQL Server
Support to discuss your options and the possible implications of running
dbcc with the repair allow data loss option. Running this has some
significant risks and you may have other options.
http://support.microsoft.com/default...offer41a&sd=GN
Thanks,
David Gerard
Microsoft SQL Server Support
Labels:
consistently,
database,
failed,
fails,
integrity,
interpret,
maintenance,
microsoft,
mysql,
oracle,
plan,
runningthe,
server,
setup,
sql,
whenattempting
How do I interpret results from a failed integrity test?
I have setup a database maintenance plan that consistently fails when
attempting to check the integrity of my database. I have tried running
the maintenance plan switching the include/exclude indexes options,
without any difference to the result. The logging report for the
failing integrity step of the maintenance plan includes the following:
=================================================================== Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
Server 'myServer' as 'myServer\myUserName' (trusted)
Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:23 AM
[1] Database myDataBase: Check Data Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
The following errors were found:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
** Execution Time: 0 hrs, 0 mins, 8 secs **
Deleting old text reports... 1 file(s) deleted.
End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:31 AM
SQLMAINT.EXE Process Exit Code: 1 (Failed)
===================================================================
From this I assume that "Extent (1:357424) in database ID 7 is
allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
What does this mean and how do I resolve the problem?
Thanks,
StephenStephen,
Check the article at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_8ape.asp.
--
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Stephen Miller" <jsausten@.hotmail.com> wrote in message
news:cdb404de.0408251803.4bd6cfdd@.posting.google.com...
> I have setup a database maintenance plan that consistently fails when
> attempting to check the integrity of my database. I have tried running
> the maintenance plan switching the include/exclude indexes options,
> without any difference to the result. The logging report for the
> failing integrity step of the maintenance plan includes the following:
> ===================================================================> Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
> Server 'myServer' as 'myServer\myUserName' (trusted)
> Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:23 AM
> [1] Database myDataBase: Check Data Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> The following errors were found:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> ** Execution Time: 0 hrs, 0 mins, 8 secs **
> Deleting old text reports... 1 file(s) deleted.
> End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:31 AM
> SQLMAINT.EXE Process Exit Code: 1 (Failed)
> ===================================================================>
> From this I assume that "Extent (1:357424) in database ID 7 is
> allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
> What does this mean and how do I resolve the problem?
> Thanks,
> Stephen|||Stephen,
If you enounter corruption related error messages the avenue most often
suggested is to restore from a known good backup. If for some reason this
is not available to you I would suggest contacting Microsoft SQL Server
Support to discuss your options and the possible implications of running
dbcc with the repair allow data loss option. Running this has some
significant risks and you may have other options.
http://support.microsoft.com/default.aspx?scid=fh;en-us;Prodoffer41a&sd=GN
Thanks,
David Gerard
Microsoft SQL Server Support
attempting to check the integrity of my database. I have tried running
the maintenance plan switching the include/exclude indexes options,
without any difference to the result. The logging report for the
failing integrity step of the maintenance plan includes the following:
=================================================================== Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
Server 'myServer' as 'myServer\myUserName' (trusted)
Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:23 AM
[1] Database myDataBase: Check Data Linkage...
[Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
The following errors were found:
[Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors not associated with any
single object.
[Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
allocation errors and 0 consistency errors in database 'myDataBase'.
[Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
is the minimum repair level for the errors found by DBCC CHECKDB
(myDataBase noindex).
** Execution Time: 0 hrs, 0 mins, 8 secs **
Deleting old text reports... 1 file(s) deleted.
End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
11:20:31 AM
SQLMAINT.EXE Process Exit Code: 1 (Failed)
===================================================================
From this I assume that "Extent (1:357424) in database ID 7 is
allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
What does this mean and how do I resolve the problem?
Thanks,
StephenStephen,
Check the article at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_reslsyserr_2_8ape.asp.
--
Dejan Sarka, SQL Server MVP
Associate Mentor
Solid Quality Learning
More than just Training
www.SolidQualityLearning.com
"Stephen Miller" <jsausten@.hotmail.com> wrote in message
news:cdb404de.0408251803.4bd6cfdd@.posting.google.com...
> I have setup a database maintenance plan that consistently fails when
> attempting to check the integrity of my database. I have tried running
> the maintenance plan switching the include/exclude indexes options,
> without any difference to the result. The logging report for the
> failing integrity step of the maintenance plan includes the following:
> ===================================================================> Microsoft (R) SQLMaint Utility (Unicode), Version Logged on to SQL
> Server 'myServer' as 'myServer\myUserName' (trusted)
> Starting maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:23 AM
> [1] Database myDataBase: Check Data Linkage...
> [Microsoft SQL-DMO (ODBC SQLState: 42000)] Error 8903:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> The following errors were found:
> [Microsoft][ODBC SQL Server Driver][SQL Server]Extent (1:357424) in
> database ID 7 is allocated in both GAM (1:2) and SGAM (1:3).
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors not associated with any
> single object.
> [Microsoft][ODBC SQL Server Driver][SQL Server]CHECKDB found 1
> allocation errors and 0 consistency errors in database 'myDataBase'.
> [Microsoft][ODBC SQL Server Driver][SQL Server]repair_allow_data_loss
> is the minimum repair level for the errors found by DBCC CHECKDB
> (myDataBase noindex).
> ** Execution Time: 0 hrs, 0 mins, 8 secs **
> Deleting old text reports... 1 file(s) deleted.
> End of maintenance plan 'myDataBase Maintenance Plan' on 26/08/2004
> 11:20:31 AM
> SQLMAINT.EXE Process Exit Code: 1 (Failed)
> ===================================================================>
> From this I assume that "Extent (1:357424) in database ID 7 is
> allocated in both GAM (1:2) and SGAM (1:3)" is the primary problem.
> What does this mean and how do I resolve the problem?
> Thanks,
> Stephen|||Stephen,
If you enounter corruption related error messages the avenue most often
suggested is to restore from a known good backup. If for some reason this
is not available to you I would suggest contacting Microsoft SQL Server
Support to discuss your options and the possible implications of running
dbcc with the repair allow data loss option. Running this has some
significant risks and you may have other options.
http://support.microsoft.com/default.aspx?scid=fh;en-us;Prodoffer41a&sd=GN
Thanks,
David Gerard
Microsoft SQL Server Support
Wednesday, March 7, 2012
How do I enable encryption?
Here's the setup.
We have an internal certificate server. (This should be OK because all
of the clients will be inside our firewall.)
Both the client and the SQL Server computer have the CA chain for the
certificate server installed.
I have a server authentication certificate installed on the SQL
Server computer using the MS Enhanced Cryptographic Provider.
(And the certificate was issued to the fully qualified domain name that
I see when I type "ping devsql1".)
I have stopped and restarted SQL Server.
Nonetheless, when I try to force encryption, I get the error
"Encryption not supported on SQL Server."
How do I get SQL Server to use the certificate, or how do I find out
why SQL Server won't use the certificate? The lack of diagnostics is
extremely frustrating.
Mike Swaim swaim@.hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
mpswaim@.mdanderson.org or mswaim@.odin.mdacc.tmc.edu at work
ICBM: 29.763N -95.363W|Disclaimer: Yeah, like I speak for MD Anderson.If you enable protocol encryption on the clientside, then the client must
also have the Trusted Root Authority updated.
If you enable protocol encryption on the serverside this isn't required.
A quick test to validate that your certificate is valid is to force
protocol encryption on the server and then restart the MSSQLServer service.
If the server starts fine, then the cert is good. Otherwise, the server
won't start and we'll know that there is either a problem with the cert or
the account used to start SQL doesn't have access to the cert store.
If the server side option works, then remove the force protocol encryption
on the server, restart the MSSQLServer service, and enable it on the client
after updating the Trusted Root Authority on the client machine.
Let me know your results.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Kevin McDonnell [MSFT] wrote:
> If you enable protocol encryption on the clientside, then the client
> must also have the Trusted Root Authority updated.
> If you enable protocol encryption on the serverside this isn't
> required.
My client has had its trusted root authority updated.
> A quick test to validate that your certificate is valid is to force
> protocol encryption on the server and then restart the MSSQLServer
> service. If the server starts fine, then the cert is good.
> Otherwise, the server won't start and we'll know that there is either
> a problem with the cert or the account used to start SQL doesn't have
> access to the cert store.
SQL Server won't start with force encryption enabled. SQL Server is
running as a custom domain account. What rights on the box does the
account need to have to access the cert store?
I'm assuming that the certificate authority is good because we have a
certificate from the same machine on our development web server, and
it's happy as a clam.
Mike Swaim swaim@.hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
mpswaim@.mdanderson.org or mswaim@.odin.mdacc.tmc.edu at work
ICBM: 29.763N -95.363W|Disclaimer: Yeah, like I speak for MD Anderson.|||Prev Post:
SQL Server won't start with force encryption enabled. SQL Server is
running as a custom domain account. What rights on the box does the
account need to have to access the cert store?
Reply:
The account that SQL Server is running under must have requested the cert.
Otherwise, the server will start and look in the local store, which only
admins have permission to, and the user store, which is probably empty.
So, what you can do is logon to the machine as the account that SQL service
is running with and request a new server certificate. Then stop n start
the mssqlserver service.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Kevin McDonnell [MSFT] wrote:
> Reply:
> The account that SQL Server is running under must have requested the
> cert. Otherwise, the server will start and look in the local store,
> which only admins have permission to, and the user store, which is
> probably empty. So, what you can do is logon to the machine as the
> account that SQL service is running with and request a new server
> certificate. Then stop n start the mssqlserver service.
Woo hoo! That did it. Thanks.
Mike Swaim swaim@.hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
mpswaim@.mdanderson.org or mswaim@.odin.mdacc.tmc.edu at work
ICBM: 29.763N -95.363W|Disclaimer: Yeah, like I speak for MD Anderson.|||You're welcome!
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
We have an internal certificate server. (This should be OK because all
of the clients will be inside our firewall.)
Both the client and the SQL Server computer have the CA chain for the
certificate server installed.
I have a server authentication certificate installed on the SQL
Server computer using the MS Enhanced Cryptographic Provider.
(And the certificate was issued to the fully qualified domain name that
I see when I type "ping devsql1".)
I have stopped and restarted SQL Server.
Nonetheless, when I try to force encryption, I get the error
"Encryption not supported on SQL Server."
How do I get SQL Server to use the certificate, or how do I find out
why SQL Server won't use the certificate? The lack of diagnostics is
extremely frustrating.
Mike Swaim swaim@.hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
mpswaim@.mdanderson.org or mswaim@.odin.mdacc.tmc.edu at work
ICBM: 29.763N -95.363W|Disclaimer: Yeah, like I speak for MD Anderson.If you enable protocol encryption on the clientside, then the client must
also have the Trusted Root Authority updated.
If you enable protocol encryption on the serverside this isn't required.
A quick test to validate that your certificate is valid is to force
protocol encryption on the server and then restart the MSSQLServer service.
If the server starts fine, then the cert is good. Otherwise, the server
won't start and we'll know that there is either a problem with the cert or
the account used to start SQL doesn't have access to the cert store.
If the server side option works, then remove the force protocol encryption
on the server, restart the MSSQLServer service, and enable it on the client
after updating the Trusted Root Authority on the client machine.
Let me know your results.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Kevin McDonnell [MSFT] wrote:
> If you enable protocol encryption on the clientside, then the client
> must also have the Trusted Root Authority updated.
> If you enable protocol encryption on the serverside this isn't
> required.
My client has had its trusted root authority updated.
> A quick test to validate that your certificate is valid is to force
> protocol encryption on the server and then restart the MSSQLServer
> service. If the server starts fine, then the cert is good.
> Otherwise, the server won't start and we'll know that there is either
> a problem with the cert or the account used to start SQL doesn't have
> access to the cert store.
SQL Server won't start with force encryption enabled. SQL Server is
running as a custom domain account. What rights on the box does the
account need to have to access the cert store?
I'm assuming that the certificate authority is good because we have a
certificate from the same machine on our development web server, and
it's happy as a clam.
Mike Swaim swaim@.hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
mpswaim@.mdanderson.org or mswaim@.odin.mdacc.tmc.edu at work
ICBM: 29.763N -95.363W|Disclaimer: Yeah, like I speak for MD Anderson.|||Prev Post:
SQL Server won't start with force encryption enabled. SQL Server is
running as a custom domain account. What rights on the box does the
account need to have to access the cert store?
Reply:
The account that SQL Server is running under must have requested the cert.
Otherwise, the server will start and look in the local store, which only
admins have permission to, and the user store, which is probably empty.
So, what you can do is logon to the machine as the account that SQL service
is running with and request a new server certificate. Then stop n start
the mssqlserver service.
Thanks,
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.|||Kevin McDonnell [MSFT] wrote:
> Reply:
> The account that SQL Server is running under must have requested the
> cert. Otherwise, the server will start and look in the local store,
> which only admins have permission to, and the user store, which is
> probably empty. So, what you can do is logon to the machine as the
> account that SQL service is running with and request a new server
> certificate. Then stop n start the mssqlserver service.
Woo hoo! That did it. Thanks.
Mike Swaim swaim@.hal-pc.org at home | Quote: "Boingie"^4 Y,W & D
MD Anderson Dept. of Biostatistics & Applied Mathematics
mpswaim@.mdanderson.org or mswaim@.odin.mdacc.tmc.edu at work
ICBM: 29.763N -95.363W|Disclaimer: Yeah, like I speak for MD Anderson.|||You're welcome!
Kevin McDonnell
Microsoft Corporation
This posting is provided AS IS with no warranties, and confers no rights.
Subscribe to:
Posts (Atom)