Let me tell you the scenario. We are doing the following to ensure we have
the fastest recovery time possible if Windows updates applied to the box
crash it.
When we get ready to apply updates to a box we want to break the driver
mirror by pulling the second drive. That way if the updates we are about to
apply break something we can just put the other drive in. But when we do this
on our test boxes the SQL databases come up suspect. Can anyone help me?
These are the steps we take.
Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows >
â'Database is now Suspectâ'."Rhild" <Rhild@.discussions.microsoft.com> wrote in message
news:EFF4313C-521D-42F1-895C-5DA19E006470@.microsoft.com...
> Let me tell you the scenario. We are doing the following to ensure we have
> the fastest recovery time possible if Windows updates applied to the box
> crash it.
> When we get ready to apply updates to a box we want to break the driver
> mirror by pulling the second drive. That way if the updates we are about
> to
> apply break something we can just put the other drive in. But when we do
> this
> on our test boxes the SQL databases come up suspect. Can anyone help me?
> These are the steps we take.
> Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows
> >
> "Database is now Suspect".
>
In theory, if this is all you're doing, it should work. I've done similiar
things.
However, it sounds like you're either pulling the wrong drive, or Windows is
somehow changing the drive letter(s) when you do this.
Check the errorlog for more details.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
Showing posts with label suspect. Show all posts
Showing posts with label suspect. Show all posts
Tuesday, March 27, 2012
Database coming up suspect.
Let me tell you the scenario. We are doing the following to ensure we have
the fastest recovery time possible if Windows updates applied to the box
crash it.
When we get ready to apply updates to a box we want to break the driver
mirror by pulling the second drive. That way if the updates we are about to
apply break something we can just put the other drive in. But when we do this
on our test boxes the SQL databases come up suspect. Can anyone help me?
These are the steps we take.
Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows >
“Database is now Suspect”.
"Rhild" <Rhild@.discussions.microsoft.com> wrote in message
news:EFF4313C-521D-42F1-895C-5DA19E006470@.microsoft.com...
> Let me tell you the scenario. We are doing the following to ensure we have
> the fastest recovery time possible if Windows updates applied to the box
> crash it.
> When we get ready to apply updates to a box we want to break the driver
> mirror by pulling the second drive. That way if the updates we are about
> to
> apply break something we can just put the other drive in. But when we do
> this
> on our test boxes the SQL databases come up suspect. Can anyone help me?
> These are the steps we take.
> Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows
> "Database is now Suspect".
>
In theory, if this is all you're doing, it should work. I've done similiar
things.
However, it sounds like you're either pulling the wrong drive, or Windows is
somehow changing the drive letter(s) when you do this.
Check the errorlog for more details.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
the fastest recovery time possible if Windows updates applied to the box
crash it.
When we get ready to apply updates to a box we want to break the driver
mirror by pulling the second drive. That way if the updates we are about to
apply break something we can just put the other drive in. But when we do this
on our test boxes the SQL databases come up suspect. Can anyone help me?
These are the steps we take.
Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows >
“Database is now Suspect”.
"Rhild" <Rhild@.discussions.microsoft.com> wrote in message
news:EFF4313C-521D-42F1-895C-5DA19E006470@.microsoft.com...
> Let me tell you the scenario. We are doing the following to ensure we have
> the fastest recovery time possible if Windows updates applied to the box
> crash it.
> When we get ready to apply updates to a box we want to break the driver
> mirror by pulling the second drive. That way if the updates we are about
> to
> apply break something we can just put the other drive in. But when we do
> this
> on our test boxes the SQL databases come up suspect. Can anyone help me?
> These are the steps we take.
> Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows
> "Database is now Suspect".
>
In theory, if this is all you're doing, it should work. I've done similiar
things.
However, it sounds like you're either pulling the wrong drive, or Windows is
somehow changing the drive letter(s) when you do this.
Check the errorlog for more details.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
Database coming up suspect.
Let me tell you the scenario. We are doing the following to ensure we have
the fastest recovery time possible if Windows updates applied to the box
crash it.
When we get ready to apply updates to a box we want to break the driver
mirror by pulling the second drive. That way if the updates we are about to
apply break something we can just put the other drive in. But when we do thi
s
on our test boxes the SQL databases come up suspect. Can anyone help me?
These are the steps we take.
Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows >
“Database is now Suspect”."Rhild" <Rhild@.discussions.microsoft.com> wrote in message
news:EFF4313C-521D-42F1-895C-5DA19E006470@.microsoft.com...
> Let me tell you the scenario. We are doing the following to ensure we have
> the fastest recovery time possible if Windows updates applied to the box
> crash it.
> When we get ready to apply updates to a box we want to break the driver
> mirror by pulling the second drive. That way if the updates we are about
> to
> apply break something we can just put the other drive in. But when we do
> this
> on our test boxes the SQL databases come up suspect. Can anyone help me?
> These are the steps we take.
> Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows
> "Database is now Suspect".
>
In theory, if this is all you're doing, it should work. I've done similiar
things.
However, it sounds like you're either pulling the wrong drive, or Windows is
somehow changing the drive letter(s) when you do this.
Check the errorlog for more details.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
the fastest recovery time possible if Windows updates applied to the box
crash it.
When we get ready to apply updates to a box we want to break the driver
mirror by pulling the second drive. That way if the updates we are about to
apply break something we can just put the other drive in. But when we do thi
s
on our test boxes the SQL databases come up suspect. Can anyone help me?
These are the steps we take.
Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows >
“Database is now Suspect”."Rhild" <Rhild@.discussions.microsoft.com> wrote in message
news:EFF4313C-521D-42F1-895C-5DA19E006470@.microsoft.com...
> Let me tell you the scenario. We are doing the following to ensure we have
> the fastest recovery time possible if Windows updates applied to the box
> crash it.
> When we get ready to apply updates to a box we want to break the driver
> mirror by pulling the second drive. That way if the updates we are about
> to
> apply break something we can just put the other drive in. But when we do
> this
> on our test boxes the SQL databases come up suspect. Can anyone help me?
> These are the steps we take.
> Shut SQL down > Turn off box > Pull drive > turn PC on > log onto windows
> "Database is now Suspect".
>
In theory, if this is all you're doing, it should work. I've done similiar
things.
However, it sounds like you're either pulling the wrong drive, or Windows is
somehow changing the drive letter(s) when you do this.
Check the errorlog for more details.
Greg Moore
SQL Server DBA Consulting
sql (at) greenms.com http://www.greenms.com
DATABASE Becomes suspect
I have a SQL 7.0 Clustered Server with SP3. Sometimes a DB (16GB) becomes
suspect and the only way to get it back online is to reboot the server and
that gets it back to normal. This happens every week.
Any ideas?
Also can you tell me how to change the location where Microsoft Clustered
Server changes the Temporary file location. Currently on my server it is
c:\winnt which we want to change
Thanks
Rod
Hey Rod, great name!
I am of no help really, but I can tell you I run 18 SQL clusters with
several Databases way larger then 16GB and we never see this. We are running
SQL 2000 on Windows Server 2003 with various hardware. If you can migrate to
a newer config, that may solve the problem.
Now, for one of the real SQL experts to help you, do you have any log events
or error messages or stats of what is going on when this occurs? Does it
happen on all the nodes? Anything else you can give will help.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://www.msmvps.com/clustering - Blog
"Rod" <Rod@.discussions.microsoft.com> wrote in message
news:77254067-96EE-46D3-BA60-EB9BA92C0D75@.microsoft.com...
>I have a SQL 7.0 Clustered Server with SP3. Sometimes a DB (16GB) becomes
> suspect and the only way to get it back online is to reboot the server and
> that gets it back to normal. This happens every week.
> Any ideas?
> Also can you tell me how to change the location where Microsoft Clustered
> Server changes the Temporary file location. Currently on my server it is
> c:\winnt which we want to change
> Thanks
> Rod
|||Hey Rodney,
My name is Rodney too. I agree Great Name.
Well here are some details/comments about the below issue:
Two things I saw on the event log were
1). The C drive was out of space. we were constantly getting the following
error in the system log:
" The Microsoft Cluster could write file (c:\winnt\CLSF9D.TMP). The Disk may
be low in space or some serious other condition exists "
The Qurorm Drive is the Q Drive.
My question is why is Cluster Server trying to write temp files to the
c:\winnt\ folder.
Can we change this location and if so how?
Thanks for your help
Rod
"Rodney R. Fournier [MVP]" wrote:
> Hey Rod, great name!
> I am of no help really, but I can tell you I run 18 SQL clusters with
> several Databases way larger then 16GB and we never see this. We are running
> SQL 2000 on Windows Server 2003 with various hardware. If you can migrate to
> a newer config, that may solve the problem.
> Now, for one of the real SQL experts to help you, do you have any log events
> or error messages or stats of what is going on when this occurs? Does it
> happen on all the nodes? Anything else you can give will help.
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://www.msmvps.com/clustering - Blog
> "Rod" <Rod@.discussions.microsoft.com> wrote in message
> news:77254067-96EE-46D3-BA60-EB9BA92C0D75@.microsoft.com...
>
>
|||Each node has its own cluster log and temp space. Why was your C drive
running out of space? Have you fixed that yet?
I am not sure how to change the WINNT temp folder that clustering writes to.
Rod
"Rod" <Rod@.discussions.microsoft.com> wrote in message
news:84068A17-BE1E-44CB-BD06-597F33A5BE91@.microsoft.com...[vbcol=seagreen]
> Hey Rodney,
> My name is Rodney too. I agree Great Name.
> Well here are some details/comments about the below issue:
> Two things I saw on the event log were
> 1). The C drive was out of space. we were constantly getting the following
> error in the system log:
> " The Microsoft Cluster could write file (c:\winnt\CLSF9D.TMP). The Disk
> may
> be low in space or some serious other condition exists "
> The Qurorm Drive is the Q Drive.
> My question is why is Cluster Server trying to write temp files to the
> c:\winnt\ folder.
> Can we change this location and if so how?
> Thanks for your help
> Rod
> "Rodney R. Fournier [MVP]" wrote:
suspect and the only way to get it back online is to reboot the server and
that gets it back to normal. This happens every week.
Any ideas?
Also can you tell me how to change the location where Microsoft Clustered
Server changes the Temporary file location. Currently on my server it is
c:\winnt which we want to change
Thanks
Rod
Hey Rod, great name!
I am of no help really, but I can tell you I run 18 SQL clusters with
several Databases way larger then 16GB and we never see this. We are running
SQL 2000 on Windows Server 2003 with various hardware. If you can migrate to
a newer config, that may solve the problem.
Now, for one of the real SQL experts to help you, do you have any log events
or error messages or stats of what is going on when this occurs? Does it
happen on all the nodes? Anything else you can give will help.
Cheers,
Rod
MVP - Windows Server - Clustering
http://www.nw-america.com - Clustering
http://www.msmvps.com/clustering - Blog
"Rod" <Rod@.discussions.microsoft.com> wrote in message
news:77254067-96EE-46D3-BA60-EB9BA92C0D75@.microsoft.com...
>I have a SQL 7.0 Clustered Server with SP3. Sometimes a DB (16GB) becomes
> suspect and the only way to get it back online is to reboot the server and
> that gets it back to normal. This happens every week.
> Any ideas?
> Also can you tell me how to change the location where Microsoft Clustered
> Server changes the Temporary file location. Currently on my server it is
> c:\winnt which we want to change
> Thanks
> Rod
|||Hey Rodney,
My name is Rodney too. I agree Great Name.
Well here are some details/comments about the below issue:
Two things I saw on the event log were
1). The C drive was out of space. we were constantly getting the following
error in the system log:
" The Microsoft Cluster could write file (c:\winnt\CLSF9D.TMP). The Disk may
be low in space or some serious other condition exists "
The Qurorm Drive is the Q Drive.
My question is why is Cluster Server trying to write temp files to the
c:\winnt\ folder.
Can we change this location and if so how?
Thanks for your help
Rod
"Rodney R. Fournier [MVP]" wrote:
> Hey Rod, great name!
> I am of no help really, but I can tell you I run 18 SQL clusters with
> several Databases way larger then 16GB and we never see this. We are running
> SQL 2000 on Windows Server 2003 with various hardware. If you can migrate to
> a newer config, that may solve the problem.
> Now, for one of the real SQL experts to help you, do you have any log events
> or error messages or stats of what is going on when this occurs? Does it
> happen on all the nodes? Anything else you can give will help.
> Cheers,
> Rod
> MVP - Windows Server - Clustering
> http://www.nw-america.com - Clustering
> http://www.msmvps.com/clustering - Blog
> "Rod" <Rod@.discussions.microsoft.com> wrote in message
> news:77254067-96EE-46D3-BA60-EB9BA92C0D75@.microsoft.com...
>
>
|||Each node has its own cluster log and temp space. Why was your C drive
running out of space? Have you fixed that yet?
I am not sure how to change the WINNT temp folder that clustering writes to.
Rod
"Rod" <Rod@.discussions.microsoft.com> wrote in message
news:84068A17-BE1E-44CB-BD06-597F33A5BE91@.microsoft.com...[vbcol=seagreen]
> Hey Rodney,
> My name is Rodney too. I agree Great Name.
> Well here are some details/comments about the below issue:
> Two things I saw on the event log were
> 1). The C drive was out of space. we were constantly getting the following
> error in the system log:
> " The Microsoft Cluster could write file (c:\winnt\CLSF9D.TMP). The Disk
> may
> be low in space or some serious other condition exists "
> The Qurorm Drive is the Q Drive.
> My question is why is Cluster Server trying to write temp files to the
> c:\winnt\ folder.
> Can we change this location and if so how?
> Thanks for your help
> Rod
> "Rodney R. Fournier [MVP]" wrote:
Database become suspect..
Hello,
One of my production database become suspect. Here is the messages taken from event veiwer-> Application Log. This is all I can share with you. Please help.
Regards
Nurullah
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
9/18/2003 12:27:57 PM MSSQLSERVER Information
-2 17055 N/A SERVERA "19013 :
SQL server listening on TCP, Shared Memory, Named Pipes.
"
--
9/18/2003 12:27:57 PM MSSQLSERVER Information
-2 17055 N/A SERVERA 17126 :
SQL Server is ready for client connections =09
--
9/18/2003 12:28:08 PM MSSQLSERVER Information
-2 17055 N/A SERVERA 8128:00:00
Using 'xpstar.dll' version '2000.80.760' to execute extended stored procedure 'sp_MSgetversion'. =09
--
9/18/2003 12:28:08 PM MSSQLSERVER Information
-2 17055 N/A SERVERA 8128:00:00
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <page.cpp>, line=3D2610 Failed Assertion =3D 'spaceNeeded <=3D spaceContig && spaceNeeded <=3D space_usable'.
"
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17055 N/A SERVERA "18052 :
Error: 3624, Severity: 20, State: 1.
"
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 644, Severity: 21, State: 5
Could not find the index entry for RID '1618d4000000100' in index page (1:9759), index ID 2, database 'eBill_Main'. "
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 3314, Severity: 21, State: 4
Error while undoing logged operation in database 'eBill_Main'. Error at log record ID (25502:819:174). "
--
9/18/2003 12:33:31 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <scanrid.cpp>, line=3D321 Failed Assertion =3D 'm_len !=3D 0'.
"
--
9/18/2003 12:33:31 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 644, Severity: 21, State: 5
Could not find the index entry for RID '=01' in index page (1:9759), index ID 2, database 'eBill_Main'. "
--
9/18/2003 12:33:34 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <logscan.cpp>, line=3D3063 Failed Assertion =3D '(m_lastLSN =3D=3D NullLSN) || (m_lastLSN > m_curLSN)'.
"
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <logscan.cpp>, line=3D3282 Failed Assertion =3D 'm_lastLSN =3D=3D NullLSN || startLSN < m_lastLSN'.
"
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 9004, Severity: 23, State: 7
An error occurred while processing the log for database 'eBill_Main'. "
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 3314, Severity: 21, State: 4
Error while undoing logged operation in database 'eBill_Main'. Error at log record ID (25502:819:174). "
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 9001, Severity: 21, State: 1
The log for database 'eBill_Main' is not available. "
--An assertion is when a piece of SQL Server's C Code goes west.
This line interested me though
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <page.cpp>, line=2610
Failed Assertion = 'spaceNeeded <= spaceContig &&
spaceNeeded <= space_usable'.
Do you have enough disk space?
What version SQL Server and SP are you running ?
Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
One of my production database become suspect. Here is the messages taken from event veiwer-> Application Log. This is all I can share with you. Please help.
Regards
Nurullah
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D
9/18/2003 12:27:57 PM MSSQLSERVER Information
-2 17055 N/A SERVERA "19013 :
SQL server listening on TCP, Shared Memory, Named Pipes.
"
--
9/18/2003 12:27:57 PM MSSQLSERVER Information
-2 17055 N/A SERVERA 17126 :
SQL Server is ready for client connections =09
--
9/18/2003 12:28:08 PM MSSQLSERVER Information
-2 17055 N/A SERVERA 8128:00:00
Using 'xpstar.dll' version '2000.80.760' to execute extended stored procedure 'sp_MSgetversion'. =09
--
9/18/2003 12:28:08 PM MSSQLSERVER Information
-2 17055 N/A SERVERA 8128:00:00
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <page.cpp>, line=3D2610 Failed Assertion =3D 'spaceNeeded <=3D spaceContig && spaceNeeded <=3D space_usable'.
"
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17055 N/A SERVERA "18052 :
Error: 3624, Severity: 20, State: 1.
"
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 644, Severity: 21, State: 5
Could not find the index entry for RID '1618d4000000100' in index page (1:9759), index ID 2, database 'eBill_Main'. "
--
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 3314, Severity: 21, State: 4
Error while undoing logged operation in database 'eBill_Main'. Error at log record ID (25502:819:174). "
--
9/18/2003 12:33:31 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <scanrid.cpp>, line=3D321 Failed Assertion =3D 'm_len !=3D 0'.
"
--
9/18/2003 12:33:31 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 644, Severity: 21, State: 5
Could not find the index entry for RID '=01' in index page (1:9759), index ID 2, database 'eBill_Main'. "
--
9/18/2003 12:33:34 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <logscan.cpp>, line=3D3063 Failed Assertion =3D '(m_lastLSN =3D=3D NullLSN) || (m_lastLSN > m_curLSN)'.
"
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <logscan.cpp>, line=3D3282 Failed Assertion =3D 'm_lastLSN =3D=3D NullLSN || startLSN < m_lastLSN'.
"
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 9004, Severity: 23, State: 7
An error occurred while processing the log for database 'eBill_Main'. "
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 3314, Severity: 21, State: 4
Error while undoing logged operation in database 'eBill_Main'. Error at log record ID (25502:819:174). "
--
9/18/2003 12:33:36 PM MSSQLSERVER Error -2
17052 N/A SERVERA "Error: 9001, Severity: 21, State: 1
The log for database 'eBill_Main' is not available. "
--An assertion is when a piece of SQL Server's C Code goes west.
This line interested me though
9/18/2003 12:33:29 PM MSSQLSERVER Error -2
17055 N/A SERVERA "17066 :
SQL Server Assertion: File: <page.cpp>, line=2610
Failed Assertion = 'spaceNeeded <= spaceContig &&
spaceNeeded <= space_usable'.
Do you have enough disk space?
What version SQL Server and SP are you running ?
Allan Mitchell (Microsoft SQL Server MVP)
MCSE,MCDBA
www.SQLDTS.com
I support PASS - the definitive, global community
for SQL Server professionals - http://www.sqlpass.org
Sunday, March 25, 2012
Database became suspect while logshipping and adding a datafile
Hello,
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we missed
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......
Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we missed
> a point. The directory, in which we created a datafile at primary site does
> not exist
> in the standby site. As another saying, we forgot to create the directory at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we try
> to restore the log. Please help.......
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we missed
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......
Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we missed
> a point. The directory, in which we created a datafile at primary site does
> not exist
> in the standby site. As another saying, we forgot to create the directory at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we try
> to restore the log. Please help.......
Database became suspect while logshipping and adding a datafile
Hello,
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we missed
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we missed
> a point. The directory, in which we created a datafile at primary site does
> not exist
> in the standby site. As another saying, we forgot to create the directory at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we try
> to restore the log. Please help.......|||Thanks for your help. Is not there a way of saving the database before making
a full
restore?
"Mark Allison" wrote:
> Erdinc,
> Do a full backup on the primary server and restore that over your DR.
> Make sure your path names are the same. Then continue as normal.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> Erdinc the logshipping man wrote:
> > Hello,
> >
> > We do loshipping between two servers. Our database in primary server
> > grew, so we had to add a datafile to the primary database. However, we missed
> > a point. The directory, in which we created a datafile at primary site does
> > not exist
> > in the standby site. As another saying, we forgot to create the directory at
> > standby
> > site before adding the datafile to primary site. Now, the standby database
> > is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> > creating the directory, and recovering the database again but nothing
> > changes, however the database becomes suspect again immediately, when we try
> > to restore the log. Please help.......
>
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we missed
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we missed
> a point. The directory, in which we created a datafile at primary site does
> not exist
> in the standby site. As another saying, we forgot to create the directory at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we try
> to restore the log. Please help.......|||Thanks for your help. Is not there a way of saving the database before making
a full
restore?
"Mark Allison" wrote:
> Erdinc,
> Do a full backup on the primary server and restore that over your DR.
> Make sure your path names are the same. Then continue as normal.
> --
> Mark Allison, SQL Server MVP
> http://www.markallison.co.uk
> Looking for a SQL Server replication book?
> http://www.nwsu.com/0974973602.html
>
> Erdinc the logshipping man wrote:
> > Hello,
> >
> > We do loshipping between two servers. Our database in primary server
> > grew, so we had to add a datafile to the primary database. However, we missed
> > a point. The directory, in which we created a datafile at primary site does
> > not exist
> > in the standby site. As another saying, we forgot to create the directory at
> > standby
> > site before adding the datafile to primary site. Now, the standby database
> > is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> > creating the directory, and recovering the database again but nothing
> > changes, however the database becomes suspect again immediately, when we try
> > to restore the log. Please help.......
>
Database became suspect while logshipping and adding a datafile
Hello,
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we misse
d
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we mis
sed
> a point. The directory, in which we created a datafile at primary site do
es
> not exist
> in the standby site. As another saying, we forgot to create the directory
at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we t
ry
> to restore the log. Please help.......
We do loshipping between two servers. Our database in primary server
grew, so we had to add a datafile to the primary database. However, we misse
d
a point. The directory, in which we created a datafile at primary site does
not exist
in the standby site. As another saying, we forgot to create the directory at
standby
site before adding the datafile to primary site. Now, the standby database
is in suspect mode, and we can not do anything. We tried sp_resetstatus,
creating the directory, and recovering the database again but nothing
changes, however the database becomes suspect again immediately, when we try
to restore the log. Please help.......Erdinc,
Do a full backup on the primary server and restore that over your DR.
Make sure your path names are the same. Then continue as normal.
--
Mark Allison, SQL Server MVP
http://www.markallison.co.uk
Looking for a SQL Server replication book?
http://www.nwsu.com/0974973602.html
Erdinc the logshipping man wrote:
> Hello,
> We do loshipping between two servers. Our database in primary server
> grew, so we had to add a datafile to the primary database. However, we mis
sed
> a point. The directory, in which we created a datafile at primary site do
es
> not exist
> in the standby site. As another saying, we forgot to create the directory
at
> standby
> site before adding the datafile to primary site. Now, the standby database
> is in suspect mode, and we can not do anything. We tried sp_resetstatus,
> creating the directory, and recovering the database again but nothing
> changes, however the database becomes suspect again immediately, when we t
ry
> to restore the log. Please help.......
Wednesday, March 7, 2012
Database "Suspect"
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
Detaching a suspect database can lead to big problems, especially since you cannot attach a corrupt database. If the database is suspect because of recovery failures, and you try to attach it again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
|||Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in message news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you cannot attach a corrupt database. If the database is suspect because of recovery failures, and you try to attach it again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
|||As I remember, the repair will remove the torn page, and all that depends on it. I.e., you never
know how much data you will lose. I strongly encourage you to either restore from a healthy backup,
or open a case with MS Support.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"FLX" <nospam@.hotmail.com> wrote in message news:%23rI67AsjEHA.556@.tk2msftngp13.phx.gbl...
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in message
news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you cannot attach a
corrupt database. If the database is suspect because of recovery failures, and you try to attach it
again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message
news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
Detaching a suspect database can lead to big problems, especially since you cannot attach a corrupt database. If the database is suspect because of recovery failures, and you try to attach it again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
|||Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in message news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you cannot attach a corrupt database. If the database is suspect because of recovery failures, and you try to attach it again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
|||As I remember, the repair will remove the torn page, and all that depends on it. I.e., you never
know how much data you will lose. I strongly encourage you to either restore from a healthy backup,
or open a case with MS Support.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"FLX" <nospam@.hotmail.com> wrote in message news:%23rI67AsjEHA.556@.tk2msftngp13.phx.gbl...
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in message
news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you cannot attach a
corrupt database. If the database is suspect because of recovery failures, and you try to attach it
again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message
news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
Database "Suspect"
For whatever reason, I have a database marked as "Suspect". I didn't find
any clue from the error log. The drive has plenty of free spaces. I don't
have the backup files. Any suggestion to recover?
Thanks a lot,
LX
Hi
Tibor Karaszi has very good article about this issue.
http://www.karaszi.com/sqlserver/default.asp
"FLX" <nospam@.hotmail.com> wrote in message
news:Olmb3%23pjEHA.3876@.TK2MSFTNGP15.phx.gbl...
> For whatever reason, I have a database marked as "Suspect". I didn't find
> any clue from the error log. The drive has plenty of free spaces. I don't
> have the backup files. Any suggestion to recover?
> Thanks a lot,
> LX
>
>
>
>
any clue from the error log. The drive has plenty of free spaces. I don't
have the backup files. Any suggestion to recover?
Thanks a lot,
LX
Hi
Tibor Karaszi has very good article about this issue.
http://www.karaszi.com/sqlserver/default.asp
"FLX" <nospam@.hotmail.com> wrote in message
news:Olmb3%23pjEHA.3876@.TK2MSFTNGP15.phx.gbl...
> For whatever reason, I have a database marked as "Suspect". I didn't find
> any clue from the error log. The drive has plenty of free spaces. I don't
> have the backup files. Any suggestion to recover?
> Thanks a lot,
> LX
>
>
>
>
Database "Suspect"
For whatever reason, I have a database marked as "Suspect". I didn't find
any clue from the error log. The drive has plenty of free spaces. I don't
have the backup files. Any suggestion to recover?
Thanks a lot,
LXHi
Tibor Karaszi has very good article about this issue.
http://www.karaszi.com/sqlserver/default.asp
"FLX" <nospam@.hotmail.com> wrote in message
news:Olmb3%23pjEHA.3876@.TK2MSFTNGP15.phx.gbl...
> For whatever reason, I have a database marked as "Suspect". I didn't find
> any clue from the error log. The drive has plenty of free spaces. I don't
> have the backup files. Any suggestion to recover?
> Thanks a lot,
> LX
>
>
>
>|||Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>|||This is a multi-part message in MIME format.
--=_NextPart_000_0023_01C48E73.F0CAC3E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Detaching a suspect database can lead to big problems, especially since =you cannot attach a corrupt database. If the database is suspect =because of recovery failures, and you try to attach it again, the attach =command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message =news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of free spaces. I don't
>have the backup files. Any suggestion to recover?
>
>Thanks a lot,
>LX
>
>
>
>
>
>
>
>
>.
>
--=_NextPart_000_0023_01C48E73.F0CAC3E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
Detaching a suspect database can lead to big =problems, especially since you cannot attach a corrupt database. If the =database is suspect because of recovery failures, and you try to attach it again, =the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." wrote in message news:08f701c48ea2$fb=cb5730$a401280a@.phx.gbl...Try dettach + attaching the database...>--Original Message-->For whatever reason, I have a database marked =as "Suspect". I didn't find>any clue from the error log. The drive =has plenty of free spaces. I don't>have the backup files. =Any suggestion to recover?>>Thanks a =lot,>LX>>>>>>>>>.>
--=_NextPart_000_0023_01C48E73.F0CAC3E0--|||This is a multi-part message in MIME format.
--=_NextPart_000_000A_01C48E96.A5005EC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in =file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in =message news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially =since you cannot attach a corrupt database. If the database is suspect =because of recovery failures, and you try to attach it again, the attach =command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message =news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of free spaces. I don't
>have the backup files. Any suggestion to recover?
>
>Thanks a lot,
>LX
>
>
>
>
>
>
>
>
>.
>
--=_NextPart_000_000A_01C48E96.A5005EC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
Exactly! That is my problem now. Here =is error message:
I/O error (torn page) detected during =read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix =it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" wrote in message news:eUfSe6qjEHA.704@.T=K2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big =problems, especially since you cannot attach a corrupt database. If the =database is suspect because of recovery failures, and you try to attach it =again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." wrote in message news:08f701c48ea2$fb=cb5730$a401280a@.phx.gbl...Try dettach + attaching the database...>--Original Message-->For whatever reason, I have a database marked =as "Suspect". I didn't find>any clue from the error log. The =drive has plenty of free spaces. I don't>have the backup =files. Any suggestion to recover?>>Thanks a =lot,>LX>>>>>>>>>.>
--=_NextPart_000_000A_01C48E96.A5005EC0--|||As I remember, the repair will remove the torn page, and all that depends on it. I.e., you never
know how much data you will lose. I strongly encourage you to either restore from a healthy backup,
or open a case with MS Support.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"FLX" <nospam@.hotmail.com> wrote in message news:%23rI67AsjEHA.556@.tk2msftngp13.phx.gbl...
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in message
news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you cannot attach a
corrupt database. If the database is suspect because of recovery failures, and you try to attach it
again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message
news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>
>Thanks a lot,
>LX
>
>
>
>
>
>
>
>
>.
>
any clue from the error log. The drive has plenty of free spaces. I don't
have the backup files. Any suggestion to recover?
Thanks a lot,
LXHi
Tibor Karaszi has very good article about this issue.
http://www.karaszi.com/sqlserver/default.asp
"FLX" <nospam@.hotmail.com> wrote in message
news:Olmb3%23pjEHA.3876@.TK2MSFTNGP15.phx.gbl...
> For whatever reason, I have a database marked as "Suspect". I didn't find
> any clue from the error log. The drive has plenty of free spaces. I don't
> have the backup files. Any suggestion to recover?
> Thanks a lot,
> LX
>
>
>
>|||Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>|||This is a multi-part message in MIME format.
--=_NextPart_000_0023_01C48E73.F0CAC3E0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Detaching a suspect database can lead to big problems, especially since =you cannot attach a corrupt database. If the database is suspect =because of recovery failures, and you try to attach it again, the attach =command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message =news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of free spaces. I don't
>have the backup files. Any suggestion to recover?
>
>Thanks a lot,
>LX
>
>
>
>
>
>
>
>
>.
>
--=_NextPart_000_0023_01C48E73.F0CAC3E0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
Detaching a suspect database can lead to big =problems, especially since you cannot attach a corrupt database. If the =database is suspect because of recovery failures, and you try to attach it again, =the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." wrote in message news:08f701c48ea2$fb=cb5730$a401280a@.phx.gbl...Try dettach + attaching the database...>--Original Message-->For whatever reason, I have a database marked =as "Suspect". I didn't find>any clue from the error log. The drive =has plenty of free spaces. I don't>have the backup files. =Any suggestion to recover?>>Thanks a =lot,>LX>>>>>>>>>.>
--=_NextPart_000_0023_01C48E73.F0CAC3E0--|||This is a multi-part message in MIME format.
--=_NextPart_000_000A_01C48E96.A5005EC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in =file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in =message news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially =since you cannot attach a corrupt database. If the database is suspect =because of recovery failures, and you try to attach it again, the attach =command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message =news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of free spaces. I don't
>have the backup files. Any suggestion to recover?
>
>Thanks a lot,
>LX
>
>
>
>
>
>
>
>
>.
>
--=_NextPart_000_000A_01C48E96.A5005EC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
&
Exactly! That is my problem now. Here =is error message:
I/O error (torn page) detected during =read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix =it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]"
Detaching a suspect database can lead to big =problems, especially since you cannot attach a corrupt database. If the =database is suspect because of recovery failures, and you try to attach it =again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." wrote in message news:08f701c48ea2$fb=cb5730$a401280a@.phx.gbl...Try dettach + attaching the database...>--Original Message-->For whatever reason, I have a database marked =as "Suspect". I didn't find>any clue from the error log. The =drive has plenty of free spaces. I don't>have the backup =files. Any suggestion to recover?>>Thanks a =lot,>LX>>>>>>>>>.>
--=_NextPart_000_000A_01C48E96.A5005EC0--|||As I remember, the repair will remove the torn page, and all that depends on it. I.e., you never
know how much data you will lose. I strongly encourage you to either restore from a healthy backup,
or open a case with MS Support.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"FLX" <nospam@.hotmail.com> wrote in message news:%23rI67AsjEHA.556@.tk2msftngp13.phx.gbl...
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in file "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in message
news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you cannot attach a
corrupt database. If the database is suspect because of recovery failures, and you try to attach it
again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message
news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>
>Thanks a lot,
>LX
>
>
>
>
>
>
>
>
>.
>
Database "Suspect"
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>Detaching a suspect database can lead to big problems, especially since you
cannot attach a corrupt database. If the database is suspect because of rec
overy failures, and you try to attach it again, the attach command will fail
.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48
ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>|||Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in fil
e "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in messa
ge news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you
cannot attach a corrupt database. If the database is suspect because of rec
overy failures, and you try to attach it again, the attach command will fail
.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48
ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>|||As I remember, the repair will remove the torn page, and all that depends on
it. I.e., you never
know how much data you will lose. I strongly encourage you to either restore
from a healthy backup,
or open a case with MS Support.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"FLX" <nospam@.hotmail.com> wrote in message news:%23rI67AsjEHA.556@.tk2msftng
p13.phx.gbl...
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in fil
e "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in messa
ge
news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you
cannot attach a
corrupt database. If the database is suspect because of recovery failures,
and you try to attach it
again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message
news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>Detaching a suspect database can lead to big problems, especially since you
cannot attach a corrupt database. If the database is suspect because of rec
overy failures, and you try to attach it again, the attach command will fail
.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48
ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>|||Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in fil
e "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in messa
ge news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you
cannot attach a corrupt database. If the database is suspect because of rec
overy failures, and you try to attach it again, the attach command will fail
.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message news:08f701c48
ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>|||As I remember, the repair will remove the torn page, and all that depends on
it. I.e., you never
know how much data you will lose. I strongly encourage you to either restore
from a healthy backup,
or open a case with MS Support.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"FLX" <nospam@.hotmail.com> wrote in message news:%23rI67AsjEHA.556@.tk2msftng
p13.phx.gbl...
Exactly! That is my problem now. Here is error message:
I/O error (torn page) detected during read at offset 0x0000002979e000 in fil
e "c:\XXXXXX"
What should I do to fix it?
Thanks in advance,
LX
"Ryan Stonecipher [MSFT]" <ryanston@.online.microsoft.com> wrote in messa
ge
news:eUfSe6qjEHA.704@.TK2MSFTNGP12.phx.gbl...
Detaching a suspect database can lead to big problems, especially since you
cannot attach a
corrupt database. If the database is suspect because of recovery failures,
and you try to attach it
again, the attach command will fail.
Thanks,
Ryan Stonecipher
Microsoft SQL Server Storage Engine.
"..." <anonymous@.discussions.microsoft.com> wrote in message
news:08f701c48ea2$fbcb5730$a401280a@.phx.gbl...
Try dettach + attaching the database...
>--Original Message--
>For whatever reason, I have a database marked
as "Suspect". I didn't find
>any clue from the error log. The drive has plenty of
free spaces. I don't
>have the backup files. Any suggestion to recover?
>Thanks a lot,
>LX
>
>
>
>
>.
>
Database "Suspect"
For whatever reason, I have a database marked as "Suspect". I didn't find
any clue from the error log. The drive has plenty of free spaces. I don't
have the backup files. Any suggestion to recover?
Thanks a lot,
LXHi
Tibor Karaszi has very good article about this issue.
http://www.karaszi.com/sqlserver/default.asp
"FLX" <nospam@.hotmail.com> wrote in message
news:Olmb3%23pjEHA.3876@.TK2MSFTNGP15.phx.gbl...
> For whatever reason, I have a database marked as "Suspect". I didn't find
> any clue from the error log. The drive has plenty of free spaces. I don't
> have the backup files. Any suggestion to recover?
> Thanks a lot,
> LX
>
>
>
>
any clue from the error log. The drive has plenty of free spaces. I don't
have the backup files. Any suggestion to recover?
Thanks a lot,
LXHi
Tibor Karaszi has very good article about this issue.
http://www.karaszi.com/sqlserver/default.asp
"FLX" <nospam@.hotmail.com> wrote in message
news:Olmb3%23pjEHA.3876@.TK2MSFTNGP15.phx.gbl...
> For whatever reason, I have a database marked as "Suspect". I didn't find
> any clue from the error log. The drive has plenty of free spaces. I don't
> have the backup files. Any suggestion to recover?
> Thanks a lot,
> LX
>
>
>
>
Databas recovery - Urgent...
i was trying to retsart mu Sql 2000 Server and one of my
database was marked suspect at start up
sp_resetstatus and restarting the server did not help me
So i detached the database - while detaching it did not
detach cleanly and it gave a msg database was uanble to
shutdown cleanly
Now when i am trying to re-attach the database using
CREATE DATABASE DCCTDG01
ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
FOR ATTACH
GO
i am getting this msg
Server: Msg 3624, Level 20, State 1, Line 1
Location:
p:\sql\ntdbms\storeng\drs\include\record.inl:1447
Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
SPID: 55
Process ID: 1316
Connection Broken
Can someone pls help me as i dont have readily accesible
backups
Thanks
SanjayHi Sanjay,
Any chance the physical database files were corrupted somehow? If so, a
restore from backup might be the only option.
HTH,
--
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Sanjay" <sanjayg@.hotmail.com> wrote in message
news:042601c39a85$7579cbb0$a401280a@.phx.gbl...
> i was trying to retsart mu Sql 2000 Server and one of my
> database was marked suspect at start up
> sp_resetstatus and restarting the server did not help me
> So i detached the database - while detaching it did not
> detach cleanly and it gave a msg database was uanble to
> shutdown cleanly
> Now when i am trying to re-attach the database using
> CREATE DATABASE DCCTDG01
> ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
> FOR ATTACH
> GO
> i am getting this msg
> Server: Msg 3624, Level 20, State 1, Line 1
> Location:
> p:\sql\ntdbms\storeng\drs\include\record.inl:1447
> Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
> SPID: 55
> Process ID: 1316
> Connection Broken
>
> Can someone pls help me as i dont have readily accesible
> backups
> Thanks
> Sanjay|||Last week there was a bulk copy to a table going on in
this database and the box hanged
When we restarted the box the K;\ (raid drive where all db
files reside) could not be recognized bcoz of some power
supply problems
This week finally we put in a new power supply and box has
started with k:\ showing up and rest of databases are fine
The only one marked suspect is this one to which BCP in
was going on while box crashed.
Is Torn Page detection that is causing the suspect'
what could have avoided this suspect status '
Sanjay
>--Original Message--
>Hi Sanjay,
>Any chance the physical database files were corrupted
somehow? If so, a
>restore from backup might be the only option.
>HTH,
>--
>Greg Low (MVP)
>MSDE Manager SQL Tools
>www.whitebearconsulting.com
>"Sanjay" <sanjayg@.hotmail.com> wrote in message
>news:042601c39a85$7579cbb0$a401280a@.phx.gbl...
>> i was trying to retsart mu Sql 2000 Server and one of my
>> database was marked suspect at start up
>> sp_resetstatus and restarting the server did not help me
>> So i detached the database - while detaching it did not
>> detach cleanly and it gave a msg database was uanble to
>> shutdown cleanly
>> Now when i am trying to re-attach the database using
>> CREATE DATABASE DCCTDG01
>> ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
>> FOR ATTACH
>> GO
>> i am getting this msg
>> Server: Msg 3624, Level 20, State 1, Line 1
>> Location:
>> p:\sql\ntdbms\storeng\drs\include\record.inl:1447
>> Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
>> SPID: 55
>> Process ID: 1316
>> Connection Broken
>>
>> Can someone pls help me as i dont have readily accesible
>> backups
>> Thanks
>> Sanjay
>
>.
>|||Hi Sanjay,
The fact that the others were ok probably just means this database was the
unlucky victim at the time. If you have backups of it from before then, I'd
be suggesting using them, particularly if it's an urgent problem.
HTH,
--
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Sanjay" <sanjayg@.hotmail.com> wrote in message
news:066d01c39ac3$efddb310$a501280a@.phx.gbl...
> Last week there was a bulk copy to a table going on in
> this database and the box hanged
> When we restarted the box the K;\ (raid drive where all db
> files reside) could not be recognized bcoz of some power
> supply problems
> This week finally we put in a new power supply and box has
> started with k:\ showing up and rest of databases are fine
> The only one marked suspect is this one to which BCP in
> was going on while box crashed.
> Is Torn Page detection that is causing the suspect'
> what could have avoided this suspect status '
> Sanjay
>
> >--Original Message--
> >Hi Sanjay,
> >
> >Any chance the physical database files were corrupted
> somehow? If so, a
> >restore from backup might be the only option.
> >
> >HTH,
> >
> >--
> >Greg Low (MVP)
> >MSDE Manager SQL Tools
> >www.whitebearconsulting.com
> >
> >"Sanjay" <sanjayg@.hotmail.com> wrote in message
> >news:042601c39a85$7579cbb0$a401280a@.phx.gbl...
> >> i was trying to retsart mu Sql 2000 Server and one of my
> >> database was marked suspect at start up
> >>
> >> sp_resetstatus and restarting the server did not help me
> >>
> >> So i detached the database - while detaching it did not
> >> detach cleanly and it gave a msg database was uanble to
> >> shutdown cleanly
> >>
> >> Now when i am trying to re-attach the database using
> >>
> >> CREATE DATABASE DCCTDG01
> >> ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
> >> FOR ATTACH
> >> GO
> >>
> >> i am getting this msg
> >>
> >> Server: Msg 3624, Level 20, State 1, Line 1
> >>
> >> Location:
> >> p:\sql\ntdbms\storeng\drs\include\record.inl:1447
> >> Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
> >> SPID: 55
> >> Process ID: 1316
> >>
> >> Connection Broken
> >>
> >>
> >> Can someone pls help me as i dont have readily accesible
> >> backups
> >>
> >> Thanks
> >> Sanjay
> >
> >
> >.
> >
database was marked suspect at start up
sp_resetstatus and restarting the server did not help me
So i detached the database - while detaching it did not
detach cleanly and it gave a msg database was uanble to
shutdown cleanly
Now when i am trying to re-attach the database using
CREATE DATABASE DCCTDG01
ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
FOR ATTACH
GO
i am getting this msg
Server: Msg 3624, Level 20, State 1, Line 1
Location:
p:\sql\ntdbms\storeng\drs\include\record.inl:1447
Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
SPID: 55
Process ID: 1316
Connection Broken
Can someone pls help me as i dont have readily accesible
backups
Thanks
SanjayHi Sanjay,
Any chance the physical database files were corrupted somehow? If so, a
restore from backup might be the only option.
HTH,
--
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Sanjay" <sanjayg@.hotmail.com> wrote in message
news:042601c39a85$7579cbb0$a401280a@.phx.gbl...
> i was trying to retsart mu Sql 2000 Server and one of my
> database was marked suspect at start up
> sp_resetstatus and restarting the server did not help me
> So i detached the database - while detaching it did not
> detach cleanly and it gave a msg database was uanble to
> shutdown cleanly
> Now when i am trying to re-attach the database using
> CREATE DATABASE DCCTDG01
> ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
> FOR ATTACH
> GO
> i am getting this msg
> Server: Msg 3624, Level 20, State 1, Line 1
> Location:
> p:\sql\ntdbms\storeng\drs\include\record.inl:1447
> Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
> SPID: 55
> Process ID: 1316
> Connection Broken
>
> Can someone pls help me as i dont have readily accesible
> backups
> Thanks
> Sanjay|||Last week there was a bulk copy to a table going on in
this database and the box hanged
When we restarted the box the K;\ (raid drive where all db
files reside) could not be recognized bcoz of some power
supply problems
This week finally we put in a new power supply and box has
started with k:\ showing up and rest of databases are fine
The only one marked suspect is this one to which BCP in
was going on while box crashed.
Is Torn Page detection that is causing the suspect'
what could have avoided this suspect status '
Sanjay
>--Original Message--
>Hi Sanjay,
>Any chance the physical database files were corrupted
somehow? If so, a
>restore from backup might be the only option.
>HTH,
>--
>Greg Low (MVP)
>MSDE Manager SQL Tools
>www.whitebearconsulting.com
>"Sanjay" <sanjayg@.hotmail.com> wrote in message
>news:042601c39a85$7579cbb0$a401280a@.phx.gbl...
>> i was trying to retsart mu Sql 2000 Server and one of my
>> database was marked suspect at start up
>> sp_resetstatus and restarting the server did not help me
>> So i detached the database - while detaching it did not
>> detach cleanly and it gave a msg database was uanble to
>> shutdown cleanly
>> Now when i am trying to re-attach the database using
>> CREATE DATABASE DCCTDG01
>> ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
>> FOR ATTACH
>> GO
>> i am getting this msg
>> Server: Msg 3624, Level 20, State 1, Line 1
>> Location:
>> p:\sql\ntdbms\storeng\drs\include\record.inl:1447
>> Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
>> SPID: 55
>> Process ID: 1316
>> Connection Broken
>>
>> Can someone pls help me as i dont have readily accesible
>> backups
>> Thanks
>> Sanjay
>
>.
>|||Hi Sanjay,
The fact that the others were ok probably just means this database was the
unlucky victim at the time. If you have backups of it from before then, I'd
be suggesting using them, particularly if it's an urgent problem.
HTH,
--
Greg Low (MVP)
MSDE Manager SQL Tools
www.whitebearconsulting.com
"Sanjay" <sanjayg@.hotmail.com> wrote in message
news:066d01c39ac3$efddb310$a501280a@.phx.gbl...
> Last week there was a bulk copy to a table going on in
> this database and the box hanged
> When we restarted the box the K;\ (raid drive where all db
> files reside) could not be recognized bcoz of some power
> supply problems
> This week finally we put in a new power supply and box has
> started with k:\ showing up and rest of databases are fine
> The only one marked suspect is this one to which BCP in
> was going on while box crashed.
> Is Torn Page detection that is causing the suspect'
> what could have avoided this suspect status '
> Sanjay
>
> >--Original Message--
> >Hi Sanjay,
> >
> >Any chance the physical database files were corrupted
> somehow? If so, a
> >restore from backup might be the only option.
> >
> >HTH,
> >
> >--
> >Greg Low (MVP)
> >MSDE Manager SQL Tools
> >www.whitebearconsulting.com
> >
> >"Sanjay" <sanjayg@.hotmail.com> wrote in message
> >news:042601c39a85$7579cbb0$a401280a@.phx.gbl...
> >> i was trying to retsart mu Sql 2000 Server and one of my
> >> database was marked suspect at start up
> >>
> >> sp_resetstatus and restarting the server did not help me
> >>
> >> So i detached the database - while detaching it did not
> >> detach cleanly and it gave a msg database was uanble to
> >> shutdown cleanly
> >>
> >> Now when i am trying to re-attach the database using
> >>
> >> CREATE DATABASE DCCTDG01
> >> ON PRIMARY (FILENAME = 'k:\DCCTDG01\DCCTDG01.mdf')
> >> FOR ATTACH
> >> GO
> >>
> >> i am getting this msg
> >>
> >> Server: Msg 3624, Level 20, State 1, Line 1
> >>
> >> Location:
> >> p:\sql\ntdbms\storeng\drs\include\record.inl:1447
> >> Expression: m_SizeRec > 0 && m_SizeRec <= MAXDATAROW
> >> SPID: 55
> >> Process ID: 1316
> >>
> >> Connection Broken
> >>
> >>
> >> Can someone pls help me as i dont have readily accesible
> >> backups
> >>
> >> Thanks
> >> Sanjay
> >
> >
> >.
> >
Databade Suspect
Hi ,
I need help , As I have mssql server with the database . Now I can not
access to this Database because the data have the suspect . How can I
Resetting the Suspect ?
Thanks and regards ,
ChuongTrang
UPDATE master..sysdatabases SET status = status^256 WHERE name = <dbname>
If the database still goes back into suspect mode, and you can't fix the
original problem, and you have no recent backup, then you can get
information out of the database by putting it into emergency mode. If you
do this, extract the data/objects out with BCP/Transfer Manager and then
rebuild the database. Note that the data may be corrupt or transactionally
inconsistent.
Issue the following command to put the database into emergency mode (you'll
need to allow updates first)
UPDATE master..sysdatabases SET status=-32768 WHERE name='<dbname>'
"Trang" <trangtran86@.hotmail.com> wrote in message
news:Oz9Ua24dDHA.3660@.TK2MSFTNGP11.phx.gbl...
> Hi ,
> I need help , As I have mssql server with the database . Now I can not
> access to this Database because the data have the suspect . How can I
> Resetting the Suspect ?
> Thanks and regards ,
> Chuong
>
I need help , As I have mssql server with the database . Now I can not
access to this Database because the data have the suspect . How can I
Resetting the Suspect ?
Thanks and regards ,
ChuongTrang
UPDATE master..sysdatabases SET status = status^256 WHERE name = <dbname>
If the database still goes back into suspect mode, and you can't fix the
original problem, and you have no recent backup, then you can get
information out of the database by putting it into emergency mode. If you
do this, extract the data/objects out with BCP/Transfer Manager and then
rebuild the database. Note that the data may be corrupt or transactionally
inconsistent.
Issue the following command to put the database into emergency mode (you'll
need to allow updates first)
UPDATE master..sysdatabases SET status=-32768 WHERE name='<dbname>'
"Trang" <trangtran86@.hotmail.com> wrote in message
news:Oz9Ua24dDHA.3660@.TK2MSFTNGP11.phx.gbl...
> Hi ,
> I need help , As I have mssql server with the database . Now I can not
> access to this Database because the data have the suspect . How can I
> Resetting the Suspect ?
> Thanks and regards ,
> Chuong
>
Subscribe to:
Posts (Atom)