Database in Recovering/suspect mode

Hi,
We have database of around 500 GB. Y'day nite we got a error msg saying
unable to write error to errorlog file.We were not able to login to the
sqlserver this morning.
So we restarted our server. It went to recover mode & started recovering
the database. It was fine till 96% then
we got a error msg
"Could not redo log record (635160:1109455:186),
for transaction ID (0:733497362), on page (4:840931), database 'VADI_NFDW'
(8). Page: LSN = (635147:63129:440), type = 2. Log: OpCode = 3, context 3,
PrevPageLSN: (635160:1100226:202)."
and one more msg as
"Error while redoing logged operation in database 'VADI_NFDW'. Error at log
record ID (635160:1109455:186)"
How could we solve this problem...It's our production db...
Thanks
Muthu
You need to contact PSS to help you with this.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"muthu" <muthu@.discussions.microsoft.com> wrote in message
news:DFB0D7F3-5236-48B9-8A4B-87BB0C1F8D24@.microsoft.com...
> Hi,
> We have database of around 500 GB. Y'day nite we got a error msg saying
> unable to write error to errorlog file.We were not able to login to the
> sqlserver this morning.
> So we restarted our server. It went to recover mode & started recovering
> the database. It was fine till 96% then
> we got a error msg
> "Could not redo log record (635160:1109455:186),
> for transaction ID (0:733497362), on page (4:840931), database 'VADI_NFDW'
> (8). Page: LSN = (635147:63129:440), type = 2. Log: OpCode = 3, context 3,
> PrevPageLSN: (635160:1100226:202)."
> and one more msg as
> "Error while redoing logged operation in database 'VADI_NFDW'. Error at
log
> record ID (635160:1109455:186)"
> How could we solve this problem...It's our production db...
> Thanks
> Muthu
>

Database in Recovering/suspect mode

Hi,
We have database of around 500 GB. Y'day nite we got a error msg saying
unable to write error to errorlog file.We were not able to login to the
sqlserver this morning.
So we restarted our server. It went to recover mode & started recovering
the database. It was fine till 96% then
we got a error msg
"Could not redo log record (635160:1109455:186),
for transaction ID (0:733497362), on page (4:840931), database 'VADI_NFDW'
(8). Page: LSN = (635147:63129:440), type = 2. Log: OpCode = 3, context 3,
PrevPageLSN: (635160:1100226:202)."
and one more msg as
"Error while redoing logged operation in database 'VADI_NFDW'. Error at log
record ID (635160:1109455:186)"
How could we solve this problem...It's our production db...
Thanks
MuthuYou need to contact PSS to help you with this.
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"muthu" <muthu@.discussions.microsoft.com> wrote in message
news:DFB0D7F3-5236-48B9-8A4B-87BB0C1F8D24@.microsoft.com...
> Hi,
> We have database of around 500 GB. Y'day nite we got a error msg saying
> unable to write error to errorlog file.We were not able to login to the
> sqlserver this morning.
> So we restarted our server. It went to recover mode & started recovering
> the database. It was fine till 96% then
> we got a error msg
> "Could not redo log record (635160:1109455:186),
> for transaction ID (0:733497362), on page (4:840931), database 'VADI_NFDW'
> (8). Page: LSN = (635147:63129:440), type = 2. Log: OpCode = 3, context 3,
> PrevPageLSN: (635160:1100226:202)."
> and one more msg as
> "Error while redoing logged operation in database 'VADI_NFDW'. Error at
log
> record ID (635160:1109455:186)"
> How could we solve this problem...It's our production db...
> Thanks
> Muthu
>

Database in Recovering/suspect mode

Hi,
We have database of around 500 GB. Y'day nite we got a error msg saying
unable to write error to errorlog file.We were not able to login to the
sqlserver this morning.
So we restarted our server. It went to recover mode & started recovering
the database. It was fine till 96% then
we got a error msg
"Could not redo log record (635160:1109455:186),
for transaction ID (0:733497362), on page (4:840931), database 'VADI_NFDW'
(8). Page: LSN = (635147:63129:440), type = 2. Log: OpCode = 3, context 3,
PrevPageLSN: (635160:1100226:202)."
and one more msg as
"Error while redoing logged operation in database 'VADI_NFDW'. Error at log
record ID (635160:1109455:186)"
How could we solve this problem...It's our production db...
Thanks
MuthuYou need to contact PSS to help you with this.
--
Paul Randal
Dev Lead, Microsoft SQL Server Storage Engine
This posting is provided "AS IS" with no warranties, and confers no rights.
"muthu" <muthu@.discussions.microsoft.com> wrote in message
news:DFB0D7F3-5236-48B9-8A4B-87BB0C1F8D24@.microsoft.com...
> Hi,
> We have database of around 500 GB. Y'day nite we got a error msg saying
> unable to write error to errorlog file.We were not able to login to the
> sqlserver this morning.
> So we restarted our server. It went to recover mode & started recovering
> the database. It was fine till 96% then
> we got a error msg
> "Could not redo log record (635160:1109455:186),
> for transaction ID (0:733497362), on page (4:840931), database 'VADI_NFDW'
> (8). Page: LSN = (635147:63129:440), type = 2. Log: OpCode = 3, context 3,
> PrevPageLSN: (635160:1100226:202)."
> and one more msg as
> "Error while redoing logged operation in database 'VADI_NFDW'. Error at
log
> record ID (635160:1109455:186)"
> How could we solve this problem...It's our production db...
> Thanks
> Muthu
>

database in a suspect mode

We have a try to migrate a winnt server to another domain,
but had to backout. Both database on the sql server are in
a suspect mode after we backedout. What can I do to bring
them back online?Can I restore them from last night's
backup? Any experiance to be shared with me...Thanks very
muchDear dk,
use this one
sp_resetstatus [ @.DBName = ] 'database'
Regards
Faheem
NETWORK SOLUTION PAKISTAN.
>--Original Message--
>We have a try to migrate a winnt server to another
domain,
>but had to backout. Both database on the sql server are
in
>a suspect mode after we backedout. What can I do to bring
>them back online?Can I restore them from last night's
>backup? Any experiance to be shared with me...Thanks very
>much
>.
>sql

Database going suspect...

I'm having trouble interpreting the errorlog for a
database which is behaving strangely.
Basically, after startup, it comes to start up
database 'JDE_Transactions' and the following appears in
the errorlog...
2003-08-04 12:00:07.51 spid10 Starting up
database 'JDE_Transactions'.
2003-08-04 12:00:07.51 spid10 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 12:00:07.61 spid10 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 12:00:11.54 spid10 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 12:00:11.56 spid10 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:55:26.95 spid9 Starting up
database 'JDE_Transactions'.
2003-08-04 15:55:26.95 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:55:26.98 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:55:30.86 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:55:30.87 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:56:53.54 spid9 Starting up
database 'JDE_Transactions'.
2003-08-04 15:56:53.54 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:56:53.57 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:56:57.46 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:56:57.48 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:57:03.22 spid9 Starting up
database 'JDE_Transactions'.
2003-08-04 15:57:03.22 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:57:03.25 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:57:07.16 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:57:07.17 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
....
This continues, with bursts of activity at different
intervals, until eventually...
2003-08-05 18:02:19.22 spid9 Starting up
database 'JDE_Transactions'.
2003-08-05 18:02:19.22 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-05 18:02:19.26 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-05 18:02:24.43 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-05 18:02:24.44 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-05 20:00:00.54 spid10 Starting up
database 'JDE_Transactions'.
2003-08-05 20:00:00.54 spid10 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-05 20:00:00.55 kernel udopen: Operating system
error 32(error not found) during the creation/opening of
physical device e:\mssql7\data\JDE_Transactions_data.mdf.
2003-08-05 20:00:00.55 kernel FCB::Open failed: Could
not open device e:\mssql7\data\JDE_Transactions_data.mdf
for virtual device number (VDN) 1.
At this point (I think), the database is marked as suspect.
Now, I have very little experience with SQL Server, but
this at first sight is a file access problem. What I don't
understand is all the open/close activity in the errorlog
over an extended period, during which the database is
accessible, and data can be retreived, seemingly as
normal - until the final errors re. failure to open
device.
Any ideas? I'd thought about doing some sort of check on
the files involved, but don't understand what the errorlog
activity is indicating. There can't be a permanent or
critical file/device access problem, otherwise the data
would never be accessible, and surely the db would fail to
open immediately.
Any suggestions gratefully received.
I should add that I'm running SQL Server 7.00.699 on NT 4.0
(1381).
Paul.It sounds like autoclose option is on for the database. Maybe when it's
closed, another process such as a virus checker is getting a handle on it
and confusing SQL when it tries to open it. You can switch off autoclose
using
exec sp_dboption 'JDE_Transactions','autoclose','false'
--
HTH
Jasper Smith (SQL Server MVP)
I support PASS - the definitive, global
community for SQL Server professionals -
http://www.sqlpass.org
"Paul M. Filby" <paulmfilby@.hotmail.com> wrote in message
news:037d01c35b9f$b3b001d0$a501280a@.phx.gbl...
I'm having trouble interpreting the errorlog for a
database which is behaving strangely.
Basically, after startup, it comes to start up
database 'JDE_Transactions' and the following appears in
the errorlog...
2003-08-04 12:00:07.51 spid10 Starting up
database 'JDE_Transactions'.
2003-08-04 12:00:07.51 spid10 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 12:00:07.61 spid10 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 12:00:11.54 spid10 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 12:00:11.56 spid10 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:55:26.95 spid9 Starting up
database 'JDE_Transactions'.
2003-08-04 15:55:26.95 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:55:26.98 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:55:30.86 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:55:30.87 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:56:53.54 spid9 Starting up
database 'JDE_Transactions'.
2003-08-04 15:56:53.54 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:56:53.57 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:56:57.46 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:56:57.48 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:57:03.22 spid9 Starting up
database 'JDE_Transactions'.
2003-08-04 15:57:03.22 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:57:03.25 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-04 15:57:07.16 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-04 15:57:07.17 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
....
This continues, with bursts of activity at different
intervals, until eventually...
2003-08-05 18:02:19.22 spid9 Starting up
database 'JDE_Transactions'.
2003-08-05 18:02:19.22 spid9 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-05 18:02:19.26 spid9 Opening file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-05 18:02:24.43 spid9 Closing file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-05 18:02:24.44 spid9 Closing file e:\MSSQL7
\data\JDE_Transactions_Log.LDF.
2003-08-05 20:00:00.54 spid10 Starting up
database 'JDE_Transactions'.
2003-08-05 20:00:00.54 spid10 Opening file e:\mssql7
\data\JDE_Transactions_data.mdf.
2003-08-05 20:00:00.55 kernel udopen: Operating system
error 32(error not found) during the creation/opening of
physical device e:\mssql7\data\JDE_Transactions_data.mdf.
2003-08-05 20:00:00.55 kernel FCB::Open failed: Could
not open device e:\mssql7\data\JDE_Transactions_data.mdf
for virtual device number (VDN) 1.
At this point (I think), the database is marked as suspect.
Now, I have very little experience with SQL Server, but
this at first sight is a file access problem. What I don't
understand is all the open/close activity in the errorlog
over an extended period, during which the database is
accessible, and data can be retreived, seemingly as
normal - until the final errors re. failure to open
device.
Any ideas? I'd thought about doing some sort of check on
the files involved, but don't understand what the errorlog
activity is indicating. There can't be a permanent or
critical file/device access problem, otherwise the data
would never be accessible, and surely the db would fail to
open immediately.
Any suggestions gratefully received.
I should add that I'm running SQL Server 7.00.699 on NT 4.0
(1381).
Paul.|||Thanks very much for that Jasper. That's exactly what was
going on. I've switched off this option now, and hopefully
that's the problem resolved!
Cheers,
Paul.
>--Original Message--
>It sounds like autoclose option is on for the database.
Maybe when it's
>closed, another process such as a virus checker is
getting a handle on it
>and confusing SQL when it tries to open it. You can
switch off autoclose
>using
>exec sp_dboption 'JDE_Transactions','autoclose','false'
>--
>HTH
>Jasper Smith (SQL Server MVP)
>I support PASS - the definitive, global
>community for SQL Server professionals -
>http://www.sqlpass.org
>"Paul M. Filby" <paulmfilby@.hotmail.com> wrote in message
>news:037d01c35b9f$b3b001d0$a501280a@.phx.gbl...
>I'm having trouble interpreting the errorlog for a
>database which is behaving strangely.
>Basically, after startup, it comes to start up
>database 'JDE_Transactions' and the following appears in
>the errorlog...
>2003-08-04 12:00:07.51 spid10 Starting up
>database 'JDE_Transactions'.
>2003-08-04 12:00:07.51 spid10 Opening file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 12:00:07.61 spid10 Opening file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-04 12:00:11.54 spid10 Closing file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 12:00:11.56 spid10 Closing file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-04 15:55:26.95 spid9 Starting up
>database 'JDE_Transactions'.
>2003-08-04 15:55:26.95 spid9 Opening file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 15:55:26.98 spid9 Opening file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-04 15:55:30.86 spid9 Closing file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 15:55:30.87 spid9 Closing file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-04 15:56:53.54 spid9 Starting up
>database 'JDE_Transactions'.
>2003-08-04 15:56:53.54 spid9 Opening file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 15:56:53.57 spid9 Opening file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-04 15:56:57.46 spid9 Closing file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 15:56:57.48 spid9 Closing file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-04 15:57:03.22 spid9 Starting up
>database 'JDE_Transactions'.
>2003-08-04 15:57:03.22 spid9 Opening file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 15:57:03.25 spid9 Opening file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-04 15:57:07.16 spid9 Closing file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-04 15:57:07.17 spid9 Closing file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>.....
>This continues, with bursts of activity at different
>intervals, until eventually...
>2003-08-05 18:02:19.22 spid9 Starting up
>database 'JDE_Transactions'.
>2003-08-05 18:02:19.22 spid9 Opening file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-05 18:02:19.26 spid9 Opening file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-05 18:02:24.43 spid9 Closing file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-05 18:02:24.44 spid9 Closing file e:\MSSQL7
>\data\JDE_Transactions_Log.LDF.
>2003-08-05 20:00:00.54 spid10 Starting up
>database 'JDE_Transactions'.
>2003-08-05 20:00:00.54 spid10 Opening file e:\mssql7
>\data\JDE_Transactions_data.mdf.
>2003-08-05 20:00:00.55 kernel udopen: Operating system
>error 32(error not found) during the creation/opening of
>physical device e:\mssql7\data\JDE_Transactions_data.mdf.
>2003-08-05 20:00:00.55 kernel FCB::Open failed: Could
>not open device e:\mssql7\data\JDE_Transactions_data.mdf
>for virtual device number (VDN) 1.
>At this point (I think), the database is marked as
suspect.
>Now, I have very little experience with SQL Server, but
>this at first sight is a file access problem. What I don't
>understand is all the open/close activity in the errorlog
>over an extended period, during which the database is
>accessible, and data can be retreived, seemingly as
>normal - until the final errors re. failure to open
>device.
>Any ideas? I'd thought about doing some sort of check on
>the files involved, but don't understand what the errorlog
>activity is indicating. There can't be a permanent or
>critical file/device access problem, otherwise the data
>would never be accessible, and surely the db would fail to
>open immediately.
>Any suggestions gratefully received.
>I should add that I'm running SQL Server 7.00.699 on NT
4.0
>(1381).
>Paul.
>
>.
>|||I'm sure Jasper is spot on. Win32 error number 32 is "the process
cannot access the file because it is being used by another process."
--
Hope this helps.
Dan Guzman
SQL Server MVP
--
SQL FAQ links (courtesy Neil Pike):
http://www.ntfaq.com/Articles/Index.cfm?DepartmentID=800
http://www.sqlserverfaq.com
http://www.mssqlserver.com/faq
--
"Paul M. Filby" <paulmfilby@.hotmail.com> wrote in message
news:040201c35ba9$8ba43120$a501280a@.phx.gbl...
> Thanks very much for that Jasper. That's exactly what was
> going on. I've switched off this option now, and hopefully
> that's the problem resolved!
> Cheers,
> Paul.
>
> >--Original Message--
> >It sounds like autoclose option is on for the database.
> Maybe when it's
> >closed, another process such as a virus checker is
> getting a handle on it
> >and confusing SQL when it tries to open it. You can
> switch off autoclose
> >using
> >
> >exec sp_dboption 'JDE_Transactions','autoclose','false'
> >
> >--
> >HTH
> >
> >Jasper Smith (SQL Server MVP)
> >
> >I support PASS - the definitive, global
> >community for SQL Server professionals -
> >http://www.sqlpass.org
> >
> >"Paul M. Filby" <paulmfilby@.hotmail.com> wrote in message
> >news:037d01c35b9f$b3b001d0$a501280a@.phx.gbl...
> >I'm having trouble interpreting the errorlog for a
> >database which is behaving strangely.
> >Basically, after startup, it comes to start up
> >database 'JDE_Transactions' and the following appears in
> >the errorlog...
> >
> >2003-08-04 12:00:07.51 spid10 Starting up
> >database 'JDE_Transactions'.
> >2003-08-04 12:00:07.51 spid10 Opening file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 12:00:07.61 spid10 Opening file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-04 12:00:11.54 spid10 Closing file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 12:00:11.56 spid10 Closing file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-04 15:55:26.95 spid9 Starting up
> >database 'JDE_Transactions'.
> >2003-08-04 15:55:26.95 spid9 Opening file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 15:55:26.98 spid9 Opening file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-04 15:55:30.86 spid9 Closing file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 15:55:30.87 spid9 Closing file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-04 15:56:53.54 spid9 Starting up
> >database 'JDE_Transactions'.
> >2003-08-04 15:56:53.54 spid9 Opening file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 15:56:53.57 spid9 Opening file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-04 15:56:57.46 spid9 Closing file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 15:56:57.48 spid9 Closing file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-04 15:57:03.22 spid9 Starting up
> >database 'JDE_Transactions'.
> >2003-08-04 15:57:03.22 spid9 Opening file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 15:57:03.25 spid9 Opening file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-04 15:57:07.16 spid9 Closing file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-04 15:57:07.17 spid9 Closing file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >.....
> >
> >This continues, with bursts of activity at different
> >intervals, until eventually...
> >
> >2003-08-05 18:02:19.22 spid9 Starting up
> >database 'JDE_Transactions'.
> >2003-08-05 18:02:19.22 spid9 Opening file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-05 18:02:19.26 spid9 Opening file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-05 18:02:24.43 spid9 Closing file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-05 18:02:24.44 spid9 Closing file e:\MSSQL7
> >\data\JDE_Transactions_Log.LDF.
> >2003-08-05 20:00:00.54 spid10 Starting up
> >database 'JDE_Transactions'.
> >2003-08-05 20:00:00.54 spid10 Opening file e:\mssql7
> >\data\JDE_Transactions_data.mdf.
> >2003-08-05 20:00:00.55 kernel udopen: Operating system
> >error 32(error not found) during the creation/opening of
> >physical device e:\mssql7\data\JDE_Transactions_data.mdf.
> >2003-08-05 20:00:00.55 kernel FCB::Open failed: Could
> >not open device e:\mssql7\data\JDE_Transactions_data.mdf
> >for virtual device number (VDN) 1.
> >
> >At this point (I think), the database is marked as
> suspect.
> >
> >Now, I have very little experience with SQL Server, but
> >this at first sight is a file access problem. What I don't
> >understand is all the open/close activity in the errorlog
> >over an extended period, during which the database is
> >accessible, and data can be retreived, seemingly as
> >normal - until the final errors re. failure to open
> >device.
> >
> >Any ideas? I'd thought about doing some sort of check on
> >the files involved, but don't understand what the errorlog
> >activity is indicating. There can't be a permanent or
> >critical file/device access problem, otherwise the data
> >would never be accessible, and surely the db would fail to
> >open immediately.
> >
> >Any suggestions gratefully received.
> >I should add that I'm running SQL Server 7.00.699 on NT
> 4.0
> >(1381).
> >Paul.
> >
> >
> >.
> >sql

Database files are "Hidden" after becoming Suspect

We had created some databases on the C Drive. Today the C drive went bad and
all the databases that
were on the C Drive became suspect.
I tried to copy the files onto another drive and I did to the D drive.
However, when I tried to attach the
datafile the data file was not showing up. I checked the properties and the
file's "Read Only" attribute was checked.
I unchecked it. However, the "Hidden" attribute has been greyed out and
looks like this is the reason why
the files are not showing up.
Would someone know how to address this problem ?
Thanks,
rgn
Hi
This is an OS issue, but here goes:
Run
ATTRIB
This returns all the files that are hidden in the current directory.
If some of your files are listed, run
ATTRIB -H <filename.ext>
This will remove the Hidden attribute on the file.
Regards
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"rgn" <gopinathr@.healthasyst.com> wrote in message
news:OUyfFwoEFHA.3244@.TK2MSFTNGP15.phx.gbl...
> We had created some databases on the C Drive. Today the C drive went bad
and
> all the databases that
> were on the C Drive became suspect.
> I tried to copy the files onto another drive and I did to the D drive.
> However, when I tried to attach the
> datafile the data file was not showing up. I checked the properties and
the
> file's "Read Only" attribute was checked.
> I unchecked it. However, the "Hidden" attribute has been greyed out and
> looks like this is the reason why
> the files are not showing up.
> Would someone know how to address this problem ?
> Thanks,
> rgn
>

Database files are "Hidden" after becoming Suspect

We had created some databases on the C Drive. Today the C drive went bad and
all the databases that
were on the C Drive became suspect.
I tried to copy the files onto another drive and I did to the D drive.
However, when I tried to attach the
datafile the data file was not showing up. I checked the properties and the
file's "Read Only" attribute was checked.
I unchecked it. However, the "Hidden" attribute has been greyed out and
looks like this is the reason why
the files are not showing up.
Would someone know how to address this problem ?
Thanks,
rgnHi
This is an OS issue, but here goes:
Run
ATTRIB
This returns all the files that are hidden in the current directory.
If some of your files are listed, run
ATTRIB -H <filename.ext>
This will remove the Hidden attribute on the file.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"rgn" <gopinathr@.healthasyst.com> wrote in message
news:OUyfFwoEFHA.3244@.TK2MSFTNGP15.phx.gbl...
> We had created some databases on the C Drive. Today the C drive went bad
and
> all the databases that
> were on the C Drive became suspect.
> I tried to copy the files onto another drive and I did to the D drive.
> However, when I tried to attach the
> datafile the data file was not showing up. I checked the properties and
the
> file's "Read Only" attribute was checked.
> I unchecked it. However, the "Hidden" attribute has been greyed out and
> looks like this is the reason why
> the files are not showing up.
> Would someone know how to address this problem ?
> Thanks,
> rgn
>

Database files are "Hidden" after becoming Suspect

We had created some databases on the C Drive. Today the C drive went bad and
all the databases that
were on the C Drive became suspect.
I tried to copy the files onto another drive and I did to the D drive.
However, when I tried to attach the
datafile the data file was not showing up. I checked the properties and the
file's "Read Only" attribute was checked.
I unchecked it. However, the "Hidden" attribute has been greyed out and
looks like this is the reason why
the files are not showing up.
Would someone know how to address this problem ?
Thanks,
rgnHi
This is an OS issue, but here goes:
Run
ATTRIB
This returns all the files that are hidden in the current directory.
If some of your files are listed, run
ATTRIB -H <filename.ext>
This will remove the Hidden attribute on the file.
Regards
--
Mike Epprecht, Microsoft SQL Server MVP
Zurich, Switzerland
IM: mike@.epprecht.net
MVP Program: http://www.microsoft.com/mvp
Blog: http://www.msmvps.com/epprecht/
"rgn" <gopinathr@.healthasyst.com> wrote in message
news:OUyfFwoEFHA.3244@.TK2MSFTNGP15.phx.gbl...
> We had created some databases on the C Drive. Today the C drive went bad
and
> all the databases that
> were on the C Drive became suspect.
> I tried to copy the files onto another drive and I did to the D drive.
> However, when I tried to attach the
> datafile the data file was not showing up. I checked the properties and
the
> file's "Read Only" attribute was checked.
> I unchecked it. However, the "Hidden" attribute has been greyed out and
> looks like this is the reason why
> the files are not showing up.
> Would someone know how to address this problem ?
> Thanks,
> rgn
>

Database Corrupted, Need help recovering data from LDF file

A friend of mine called and said that his database was suspect and he detached it and was unable to attach it. The SQL Server Version is 2000 with the latest service packs installed. When I checked it the database (MDF) size was 1MB and the LDF size was 3.8 GB. I was not able to attach the two together and I was not able to attach the database using sp_attach_single_file_db. I did find an old backup of his database and attached that so he can work off of it but it is 1 yr old and he needs recent data. Since the MDF seemed to be blank we cant do much with that, but there seems to be data in the LDF. Is it possible to extract any data from the LDF file?

SunnyThe log file contains low level physical changes that are almost impossible to correlate with user objects without the metadata in the data files.

Database Corrupted, Need help recovering data from LDF file

A friend of mine called and said that his database was suspect and he detached it and was unable to attach it. The SQL Server Version is 2000 with the latest service packs installed. When I checked it the database (MDF) size was 1MB and the LDF size was 3.8 GB. I was not able to attach the two together and I was not able to attach the database using sp_attach_single_file_db. I did find an old backup of his database and attached that so he can work off of it but it is 1 yr old and he needs recent data. Since the MDF seemed to be blank we cant do much with that, but there seems to be data in the LDF. Is it possible to extract any data from the LDF file?

SunnyThe log file contains low level physical changes that are almost impossible to correlate with user objects without the metadata in the data files.