Showing posts with label utility. Show all posts
Showing posts with label utility. Show all posts

Monday, March 26, 2012

error 823, severity 24, state2

The following messages seems happen every two weeks. it may cause by hardwar
e
error, but HP Array Utility hasn't detected any error. Any ideas, does it
make sense to move database to the local hard drive?
Error: 823, Severity: 24, State: 2
I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
Data:Words
0000: 00000337 00000018 00000009 00550053
0010: 0044004e 00540041 00310041 00070000
0020: 00530000 004e0055 00440035 00000042
SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA 1000,
the database is on SAN disks.Sounds like you may have some corruption in the database.
Try running the DBCC CHECKCATALOG and see what you get back. BOL has some
great suggestions on the usage as well as some others like DBCC CHECKTABLE
and DBCC CHECKxxxxxx
Rick Sawtell
MCT, MCSD, MCDBA
"Joshua" <Joshua@.discussions.microsoft.com> wrote in message
news:A1DF380C-CB99-4125-A713-7E14303C6125@.microsoft.com...
> The following messages seems happen every two weeks. it may cause by
> hardware
> error, but HP Array Utility hasn't detected any error. Any ideas, does it
> make sense to move database to the local hard drive?
> Error: 823, Severity: 24, State: 2
> I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
> file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
> Data:Words
> 0000: 00000337 00000018 00000009 00550053
> 0010: 0044004e 00540041 00310041 00070000
> 0020: 00530000 004e0055 00440035 00000042
> SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA
> 1000,
> the database is on SAN disks.

error 823, severity 24, state2

The following messages seems happen every two weeks. it may cause by hardware
error, but HP Array Utility hasn't detected any error. Any ideas, does it
make sense to move database to the local hard drive?
Error: 823, Severity: 24, State: 2
I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
Data:Words
0000: 00000337 00000018 00000009 00550053
0010: 0044004e 00540041 00310041 00070000
0020: 00530000 004e0055 00440035 00000042
SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA 1000,
the database is on SAN disks.
Sounds like you may have some corruption in the database.
Try running the DBCC CHECKCATALOG and see what you get back. BOL has some
great suggestions on the usage as well as some others like DBCC CHECKTABLE
and DBCC CHECKxxxxxx
Rick Sawtell
MCT, MCSD, MCDBA
"Joshua" <Joshua@.discussions.microsoft.com> wrote in message
news:A1DF380C-CB99-4125-A713-7E14303C6125@.microsoft.com...
> The following messages seems happen every two weeks. it may cause by
> hardware
> error, but HP Array Utility hasn't detected any error. Any ideas, does it
> make sense to move database to the local hard drive?
> Error: 823, Severity: 24, State: 2
> I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
> file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
> Data:Words
> 0000: 00000337 00000018 00000009 00550053
> 0010: 0044004e 00540041 00310041 00070000
> 0020: 00530000 004e0055 00440035 00000042
> SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA
> 1000,
> the database is on SAN disks.
|||Generally the first thing you do is look up the error number in Books On
line... Here is the info from BOL
Error 823
Severity Level 24
Message Text
I/O error %ls detected during %S_MSG at offset %#016I64x in file '%ls'.
Explanation
Microsoft SQL ServerT encountered an I/O error on a read or write request
made to a device. This error usually indicates disk problems. However,
additional kernel messages in the error log, recorded before error 823,
should indicate which device is involved.
Action
Check the accessibility and condition of the device in question.
Run hardware diagnostics and correct problems, if possible.
Restore damaged files from the latest database backup. Restoring from a
database backup should always be considered the primary means of fixing a
damaged database.
If you don't have a backup or if the errors detected are very isolated, the
repair functionality of DBCC CHECKDB may be useful. However, using DBCC
CHECKDB can be more time consuming than restoring the damaged files from a
backup, and you may not be able to recover all your data .
Caution If running DBCC CHECKDB with one of the repair clauses does not
correct the problem or if you are unsure how this process may affect your
data, contact your primary support provider.
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Joshua" <Joshua@.discussions.microsoft.com> wrote in message
news:A1DF380C-CB99-4125-A713-7E14303C6125@.microsoft.com...
> The following messages seems happen every two weeks. it may cause by
hardware
> error, but HP Array Utility hasn't detected any error. Any ideas, does it
> make sense to move database to the local hard drive?
> Error: 823, Severity: 24, State: 2
> I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
> file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
> Data:Words
> 0000: 00000337 00000018 00000009 00550053
> 0010: 0044004e 00540041 00310041 00070000
> 0020: 00530000 004e0055 00440035 00000042
> SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA
1000,
> the database is on SAN disks.
begin 666 caution.gif
M1TE&.#EA# `+`/<``````#,``&8``)D``,P``/\````S`#,S`&8S`)DS`,PS
M`/\S``!F`#-F`&9F`)EF`,QF`/]F``"9`#.9`&:9`)F9`,R9`/^9``#,`#/,
M`&;,`)G,`,S,`/_,``#_`#/_`&;_`)G_`,S_`/__````,S,`,V8`,YD`,\P`
M,_\`,P`S,S,S,V8S,YDS,\PS,_\S,P!F,S-F,V9F,YEF,\QF,_]F,P"9,S.9
M,V:9,YF9,\R9,_^9,P#,,S/,,V;,,YG,,\S,,__,,P#_,S/_,V;_,YG_,\S_
M,___,P``9C,`9F8`9ID`9LP`9O\`9@.`S9C,S9F8S9IDS9LPS9 O\S9@.!F9C-F
M9F9F9IEF9LQF9O]F9@."99C.99F:99IF99LR99O^99@.#,9C/,9F;,9IG,9LS,
M9O_,9@.#_9C/_9F;_9IG_9LS_9O__9@.``F3,`F68`F9D`F<P`F?\`F0`SF3,S
MF68SF9DSF<PSF?\SF0!FF3-FF69FF9EFF<QFF?]FF0"9F3.9F6:9F9F9F<R9
MF?^9F0#,F3/,F6;,F9G,F<S,F?_,F0#_F3/_F6;_F9G_F<S_F?__F0``S#,`
MS&8`S)D`S,P`S/\`S `SS#,SS&8SS)DSS,PSS/\SS !FS#-FS&9FS)EFS,QF
MS/]FS "9S#.9S&:9S)F9S,R9S/^9S #,S#/,S&;,S)G,S,S,S/_,S #_S#/_
MS&;_S)G_S,S_S/__S ``_S,`_V8`_YD`_\P`__\`_P`S_S,S_V8S_YDS_\PS
M__\S_P!F_S-F_V9F_YEF_\QF__]F_P"9_S.9_V:9_YF9_\R9__^9_P#,_S/,
M_V;,_YG,_\S,___,_P#__S/__V;__YG__\S______P``````````````````
M````````````````````````````````````````````````` ```````````
M````````````````````````````````````````````````` ```````````
M`````````````````````"'Y! $``*P`+ `````,``L`0 @.B`%D)'$BPH,&#
;K HH1)AP(4*%!1A"9$A1X,2'#BMBC#@.P( `[
`
end

error 823, severity 24, state2

The following messages seems happen every two weeks. it may cause by hardware
error, but HP Array Utility hasn't detected any error. Any ideas, does it
make sense to move database to the local hard drive?
Error: 823, Severity: 24, State: 2
I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
Data:Words
0000: 00000337 00000018 00000009 00550053
0010: 0044004e 00540041 00310041 00070000
0020: 00530000 004e0055 00440035 00000042
SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA 1000,
the database is on SAN disks.Sounds like you may have some corruption in the database.
Try running the DBCC CHECKCATALOG and see what you get back. BOL has some
great suggestions on the usage as well as some others like DBCC CHECKTABLE
and DBCC CHECKxxxxxx
Rick Sawtell
MCT, MCSD, MCDBA
"Joshua" <Joshua@.discussions.microsoft.com> wrote in message
news:A1DF380C-CB99-4125-A713-7E14303C6125@.microsoft.com...
> The following messages seems happen every two weeks. it may cause by
> hardware
> error, but HP Array Utility hasn't detected any error. Any ideas, does it
> make sense to move database to the local hard drive?
> Error: 823, Severity: 24, State: 2
> I/O error (bad page ID) detected during read at offset 0x0000016d7fa000 in
> file 'E:\SQLDATA\MSSQL\Data\SUN5DB_data.mdf'.
> Data:Words
> 0000: 00000337 00000018 00000009 00550053
> 0010: 0044004e 00540041 00310041 00070000
> 0020: 00530000 004e0055 00440035 00000042
> SQL Enterprise 2000 Server, Windows 2000 Enterprise Server, Compaq MSA
> 1000,
> the database is on SAN disks.

Friday, February 24, 2012

Error 3: the system cannot find the specified path

Installed SQL Server 2000 Enterprise trial a week ago on XP Pro. Installed new Seagate 80G HD; used Seagate's utility to copy old C: to new drive as new boot drive. All seems to work fine, except, when booting up, SQL server doesn't start. When I try to start it manually I get the following:

Could not start SQLSERVER service on the local computer. Error 3: the system cannot find the specified path.

1. What could be wrong?

2. How do I fix it?

If you are starting via the service, look at services.msc and see what path is pointed to for sqlservr.exe. Check if the file exists at this location. Is this error coming from SQL Server or the OS?

|||

I saw nothing in services.msc relating to sql. In fact, the file is dated 8/4/2004. I didn't install SQL until about a week ago. [[NOTE, FYI: I also posted this question in the 'SQL Server Data Access' forum, but no solution there yet, either]]. If I try to manually start SQL Server, the first message just states it's unable to find the path specified. When I click OK, the next message title bar reads 'SQL Server Service Manager', and the message reads, "An error 3 - (The system cannot find the path specified.

) occured while performing this service operation on the MSSQLServer service."

If you're referring to the properties in Services, MSSQLServer, properties, the path is "C:\PROGRA~1\MICROS~4\MSSQL\binn\sqlservr.exe"

If I navigate to C:\Program Files\Microsoft SQL Server\MSSQL\Binn, I can double-click sqlservr.exe and a dos window opens up, etc., but it doesn' t seem to do anything related to the icon in my status bar, which still shows not started. If I enter the ..~ path above into the command prompt, I get the same "The system cannot find the path specified". Looks like I need to change the path to mssql server, but how do I do that?

|||

Services.msc is the MMC Services extension. It is an dll that will be loaded and run by MMC.

Change to that path in a cmd.exe window, and run sqlservr.exe -c. It should log to the console and ERRORLOG the error message. You can also try to track the file is searching for with filemon (www.sysinternals.com tool).

|||

SQLServer need somewehree a starting point, there for the path to the master mdf is coded in the registry with the appropiate start parameter. The service gathers this information at start up to find the "valid mointing point" for the master database. The key normally is located on the node

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\Parameters

Changing this is sort of critical, so you better save your registry key first to restore it, if something unexpectly happens.

HTH, Jens Suessmeyer.


http://www.sqlserver2005.de


||| Actually, I found that yesterday; changed two path settings in the registry, and that fixed it. Apparently, when I duplicated the hard drive, it somehow used the DOS ~ naming conventions. Once I changed back to the named path, all seemed to work fine. Thanks to all who replied to my question.|||

I just ran into the same problem after I migrate (duplicate) the server to another server. I checked the properties under service of mssqlserver and it displayed the shortname. I went into the registry and made modification to a few places under HKLM\system\currentcontrolset....\service\mssqlserver and changed the imagepath parameter to point to the proper long name E:\progam files\microsoft sql server\mssql\binn\sqlsrver.exe. Then I was able to start SQL Server. The properties of SQLserver agent is using the long name so it does not have a problem.

I don't understand why it did not work. I checked the old server and it was using the short name and it worked. I checked some other SQL servers and they all displayed the short name and they have no problem. I thought the system should be able to recognize the short name automatically.

It seems that this problem is only happening on this server.

Any idea?

Thanks.

Error 3: the system cannot find the specified path

Installed SQL Server 2000 Enterprise trial a week ago on XP Pro. Installed new Seagate 80G HD; used Seagate's utility to copy old C: to new drive as new boot drive. All seems to work fine, except, when booting up, SQL server doesn't start. When I try to start it manually I get the following:

Could not start SQLSERVER service on the local computer. Error 3: the system cannot find the specified path.

1. What could be wrong?

2. How do I fix it?

If you are starting via the service, look at services.msc and see what path is pointed to for sqlservr.exe. Check if the file exists at this location. Is this error coming from SQL Server or the OS?

|||

I saw nothing in services.msc relating to sql. In fact, the file is dated 8/4/2004. I didn't install SQL until about a week ago. [[NOTE, FYI: I also posted this question in the 'SQL Server Data Access' forum, but no solution there yet, either]]. If I try to manually start SQL Server, the first message just states it's unable to find the path specified. When I click OK, the next message title bar reads 'SQL Server Service Manager', and the message reads, "An error 3 - (The system cannot find the path specified.

) occured while performing this service operation on the MSSQLServer service."

If you're referring to the properties in Services, MSSQLServer, properties, the path is "C:\PROGRA~1\MICROS~4\MSSQL\binn\sqlservr.exe"

If I navigate to C:\Program Files\Microsoft SQL Server\MSSQL\Binn, I can double-click sqlservr.exe and a dos window opens up, etc., but it doesn' t seem to do anything related to the icon in my status bar, which still shows not started. If I enter the ..~ path above into the command prompt, I get the same "The system cannot find the path specified". Looks like I need to change the path to mssql server, but how do I do that?

|||

Services.msc is the MMC Services extension. It is an dll that will be loaded and run by MMC.

Change to that path in a cmd.exe window, and run sqlservr.exe -c. It should log to the console and ERRORLOG the error message. You can also try to track the file is searching for with filemon (www.sysinternals.com tool).

|||

SQLServer need somewehree a starting point, there for the path to the master mdf is coded in the registry with the appropiate start parameter. The service gathers this information at start up to find the "valid mointing point" for the master database. The key normally is located on the node

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\Parameters

Changing this is sort of critical, so you better save your registry key first to restore it, if something unexpectly happens.

HTH, Jens Suessmeyer.


http://www.sqlserver2005.de


||| Actually, I found that yesterday; changed two path settings in the registry, and that fixed it. Apparently, when I duplicated the hard drive, it somehow used the DOS ~ naming conventions. Once I changed back to the named path, all seemed to work fine. Thanks to all who replied to my question.|||

I just ran into the same problem after I migrate (duplicate) the server to another server. I checked the properties under service of mssqlserver and it displayed the shortname. I went into the registry and made modification to a few places under HKLM\system\currentcontrolset....\service\mssqlserver and changed the imagepath parameter to point to the proper long name E:\progam files\microsoft sql server\mssql\binn\sqlsrver.exe. Then I was able to start SQL Server. The properties of SQLserver agent is using the long name so it does not have a problem.

I don't understand why it did not work. I checked the old server and it was using the short name and it worked. I checked some other SQL servers and they all displayed the short name and they have no problem. I thought the system should be able to recognize the short name automatically.

It seems that this problem is only happening on this server.

Any idea?

Thanks.