Have you ever got this TempDB error ?

My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
By default, the TempDB locates at C drive and I increased its size by adding
2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
However, I don't know why the TempDB always cannot recognize these 2 D-drive
files when I come to office every morning.
The 2 D-drive files still exist in D drive but from the SQL Enterprise
Manager tells me the TempDB only has C-drive files.
Why, why the D-drive file pointers always become invvalid ?
Hi,
Can you execute the below statement in query analyzer:-
sp_helpdb tempdb
If it is not showing D drive file, then you have not added the new files
properly.
Refer ALTER DATABASE in books online to add a new file to D Drive. (You can
also use Enterprise manager)
Thanks
Hari
MCDBA
"cpchan" <cpchaney@.netvigator.com> wrote in message
news:c97hfp$rtr2@.imsp212.netvigator.com...
> My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> By default, the TempDB locates at C drive and I increased its size by
adding
> 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> However, I don't know why the TempDB always cannot recognize these 2
D-drive
> files when I come to office every morning.
> The 2 D-drive files still exist in D drive but from the SQL Enterprise
> Manager tells me the TempDB only has C-drive files.
> Why, why the D-drive file pointers always become invvalid ?
>
>
|||What does "cannot recognize" mean? Do you get an error message (as your
subject implies)? If so, what is it?
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"cpchan" <cpchaney@.netvigator.com> wrote in message
news:c97hfp$rtr2@.imsp212.netvigator.com...
> My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> By default, the TempDB locates at C drive and I increased its size by
adding
> 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> However, I don't know why the TempDB always cannot recognize these 2
D-drive
> files when I come to office every morning.
> The 2 D-drive files still exist in D drive but from the SQL Enterprise
> Manager tells me the TempDB only has C-drive files.
> Why, why the D-drive file pointers always become invvalid ?
>
>
|||It means in SQL Enterprise Manager, it only says the TempDB has 2 C-drive
files but not have the 2 D-drive files I added last night.
However, the 2 D-drive files still exist in the D drive when I used File
Explorer to search them.
"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
news:#uPqAqMREHA.2972@.TK2MSFTNGP09.phx.gbl...
> What does "cannot recognize" mean? Do you get an error message (as your
> subject implies)? If so, what is it?
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>
>
> "cpchan" <cpchaney@.netvigator.com> wrote in message
> news:c97hfp$rtr2@.imsp212.netvigator.com...
> adding
> D-drive
>
|||Hi,
Can you execute the below statement in query analyzer:-
sp_helpdb tempdb
If it is not showing D drive file, then you have not added the new files
properly. Please recreate the files using using ALTER DATABASE command.
Thanks
Hari
MCDBA
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:ezZkyaMREHA.3944@.TK2MSFTNGP11.phx.gbl...
> Hi,
> Can you execute the below statement in query analyzer:-
> sp_helpdb tempdb
> If it is not showing D drive file, then you have not added the new files
> properly.
> Refer ALTER DATABASE in books online to add a new file to D Drive. (You
can
> also use Enterprise manager)
> Thanks
> Hari
> MCDBA
>
> "cpchan" <cpchaney@.netvigator.com> wrote in message
> news:c97hfp$rtr2@.imsp212.netvigator.com...
> adding
> D-drive
>

Have you ever got this TempDB error ?

My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
By default, the TempDB locates at C drive and I increased its size by adding
2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
However, I don't know why the TempDB always cannot recognize these 2 D-drive
files when I come to office every morning.
The 2 D-drive files still exist in D drive but from the SQL Enterprise
Manager tells me the TempDB only has C-drive files.
Why, why the D-drive file pointers always become invvalid ?Hi,
Can you execute the below statement in query analyzer:-
sp_helpdb tempdb
If it is not showing D drive file, then you have not added the new files
properly.
Refer ALTER DATABASE in books online to add a new file to D Drive. (You can
also use Enterprise manager)
Thanks
Hari
MCDBA
"cpchan" <cpchaney@.netvigator.com> wrote in message
news:c97hfp$rtr2@.imsp212.netvigator.com...
> My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> By default, the TempDB locates at C drive and I increased its size by
adding
> 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> However, I don't know why the TempDB always cannot recognize these 2
D-drive
> files when I come to office every morning.
> The 2 D-drive files still exist in D drive but from the SQL Enterprise
> Manager tells me the TempDB only has C-drive files.
> Why, why the D-drive file pointers always become invvalid ?
>
>|||What does "cannot recognize" mean? Do you get an error message (as your
subject implies)? If so, what is it?
--
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"cpchan" <cpchaney@.netvigator.com> wrote in message
news:c97hfp$rtr2@.imsp212.netvigator.com...
> My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> By default, the TempDB locates at C drive and I increased its size by
adding
> 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> However, I don't know why the TempDB always cannot recognize these 2
D-drive
> files when I come to office every morning.
> The 2 D-drive files still exist in D drive but from the SQL Enterprise
> Manager tells me the TempDB only has C-drive files.
> Why, why the D-drive file pointers always become invvalid ?
>
>|||It means in SQL Enterprise Manager, it only says the TempDB has 2 C-drive
files but not have the 2 D-drive files I added last night.
However, the 2 D-drive files still exist in the D drive when I used File
Explorer to search them.
"Aaron Bertrand - MVP" <aaron@.TRASHaspfaq.com> wrote in message
news:#uPqAqMREHA.2972@.TK2MSFTNGP09.phx.gbl...
> What does "cannot recognize" mean? Do you get an error message (as your
> subject implies)? If so, what is it?
> --
> Aaron Bertrand
> SQL Server MVP
> http://www.aspfaq.com/
>
>
> "cpchan" <cpchaney@.netvigator.com> wrote in message
> news:c97hfp$rtr2@.imsp212.netvigator.com...
> > My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> > By default, the TempDB locates at C drive and I increased its size by
> adding
> > 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> >
> > However, I don't know why the TempDB always cannot recognize these 2
> D-drive
> > files when I come to office every morning.
> > The 2 D-drive files still exist in D drive but from the SQL Enterprise
> > Manager tells me the TempDB only has C-drive files.
> >
> > Why, why the D-drive file pointers always become invvalid ?
> >
> >
> >
>|||Hi,
Can you execute the below statement in query analyzer:-
sp_helpdb tempdb
If it is not showing D drive file, then you have not added the new files
properly. Please recreate the files using using ALTER DATABASE command.
Thanks
Hari
MCDBA
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:ezZkyaMREHA.3944@.TK2MSFTNGP11.phx.gbl...
> Hi,
> Can you execute the below statement in query analyzer:-
> sp_helpdb tempdb
> If it is not showing D drive file, then you have not added the new files
> properly.
> Refer ALTER DATABASE in books online to add a new file to D Drive. (You
can
> also use Enterprise manager)
> Thanks
> Hari
> MCDBA
>
> "cpchan" <cpchaney@.netvigator.com> wrote in message
> news:c97hfp$rtr2@.imsp212.netvigator.com...
> > My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> > By default, the TempDB locates at C drive and I increased its size by
> adding
> > 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> >
> > However, I don't know why the TempDB always cannot recognize these 2
> D-drive
> > files when I come to office every morning.
> > The 2 D-drive files still exist in D drive but from the SQL Enterprise
> > Manager tells me the TempDB only has C-drive files.
> >
> > Why, why the D-drive file pointers always become invvalid ?
> >
> >
> >
>

Have you ever got this TempDB error ?

My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
By default, the TempDB locates at C drive and I increased its size by adding
2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
However, I don't know why the TempDB always cannot recognize these 2 D-drive
files when I come to office every morning.
The 2 D-drive files still exist in D drive but from the SQL Enterprise
Manager tells me the TempDB only has C-drive files.
Why, why the D-drive file pointers always become invvalid ?Hi,
Can you execute the below statement in query analyzer:-
sp_helpdb tempdb
If it is not showing D drive file, then you have not added the new files
properly.
Refer ALTER DATABASE in books online to add a new file to D Drive. (You can
also use Enterprise manager)
Thanks
Hari
MCDBA
"cpchan" <cpchaney@.netvigator.com> wrote in message
news:c97hfp$rtr2@.imsp212.netvigator.com...
> My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> By default, the TempDB locates at C drive and I increased its size by
adding
> 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> However, I don't know why the TempDB always cannot recognize these 2
D-drive
> files when I come to office every morning.
> The 2 D-drive files still exist in D drive but from the SQL Enterprise
> Manager tells me the TempDB only has C-drive files.
> Why, why the D-drive file pointers always become invvalid ?
>
>|||What does "cannot recognize" mean? Do you get an error message (as your
subject implies)? If so, what is it?
Aaron Bertrand
SQL Server MVP
http://www.aspfaq.com/
"cpchan" <cpchaney@.netvigator.com> wrote in message
news:c97hfp$rtr2@.imsp212.netvigator.com...
> My SQL Server 7.0 (with Service Pack 3) server has 3 drives : C, D, E.
> By default, the TempDB locates at C drive and I increased its size by
adding
> 2 more files (1 for TempDB database file and 1 for Temp log) at D drive.
> However, I don't know why the TempDB always cannot recognize these 2
D-drive
> files when I come to office every morning.
> The 2 D-drive files still exist in D drive but from the SQL Enterprise
> Manager tells me the TempDB only has C-drive files.
> Why, why the D-drive file pointers always become invvalid ?
>
>

Have an .mdf file but can't seem to attach it.

We had a server that was having all kinds of problems. We finally got it
booted and I copied the .MDF file off the hard drive. I'm trying to create a
new database on a different machine using this .MDF file and it appears to
not work. I had shut down SQL on the machine before I copied the file but I
didn't detach it ( didn't have the time and I was trying to explain it to
somebody else. ) So now I have this .MDF file that I can't attach. I'm doing
the following command:
use master
go
CREATE DATABASE BugTracking on (Filename='D:\Program Files\Microsoft SQL
Server\MSSQL\Data\BugTracking.mdf') for attach
go
and I'm getting the following error:
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'BugTracking'. CREATE DATABASE is aborted.
Msg 602, Level 21, State 50, Line 1
Could not find row in sysindexes for database ID 23, object ID 1, index ID
1. Run DBCC CHECKTABLE on sysindexes.
I've also tried to a direct attach deleting the log file and it won't do it.
Anybody have any thoughts?
TIA - Jeff.
Can you try sp_attach_single_file_db and see if it works?
See:
http://msdn2.microsoft.com/en-us/library/ms174385(SQL.90).aspx

Adam Machanic
SQL Server MVP
Author, "Expert SQL Server 2005 Development"
http://www.apress.com/book/bookDisplay.html?bID=10220
"Mufasa" <jb@.nowhere.com> wrote in message
news:eH$ODo1sHHA.840@.TK2MSFTNGP03.phx.gbl...
> We had a server that was having all kinds of problems. We finally got it
> booted and I copied the .MDF file off the hard drive. I'm trying to create
> a new database on a different machine using this .MDF file and it appears
> to not work. I had shut down SQL on the machine before I copied the file
> but I didn't detach it ( didn't have the time and I was trying to explain
> it to somebody else. ) So now I have this .MDF file that I can't attach.
> I'm doing the following command:
>
> use master
> go
> CREATE DATABASE BugTracking on (Filename='D:\Program Files\Microsoft SQL
> Server\MSSQL\Data\BugTracking.mdf') for attach
> go
>
> and I'm getting the following error:
>
> Msg 1813, Level 16, State 2, Line 1
> Could not open new database 'BugTracking'. CREATE DATABASE is aborted.
> Msg 602, Level 21, State 50, Line 1
> Could not find row in sysindexes for database ID 23, object ID 1, index ID
> 1. Run DBCC CHECKTABLE on sysindexes.
>
> I've also tried to a direct attach deleting the log file and it won't do
> it.
> Anybody have any thoughts?
> TIA - Jeff.
>
|||Sorry everybody - I finally figured out what was wrong - I was trying to
attach the file from a 2005 db into 2000. Once I switched to another server,
it worked fine.
J.
"Adam Machanic" <amachanic@.IHATESPAMgmail.com> wrote in message
news:E95832E9-C1D4-4BC3-B010-6F7079F2AEAF@.microsoft.com...
> Can you try sp_attach_single_file_db and see if it works?
> See:
> http://msdn2.microsoft.com/en-us/library/ms174385(SQL.90).aspx
>
> --
> Adam Machanic
> SQL Server MVP
> Author, "Expert SQL Server 2005 Development"
> http://www.apress.com/book/bookDisplay.html?bID=10220
>
> "Mufasa" <jb@.nowhere.com> wrote in message
> news:eH$ODo1sHHA.840@.TK2MSFTNGP03.phx.gbl...
>

Have an .mdf file but can't seem to attach it.

We had a server that was having all kinds of problems. We finally got it
booted and I copied the .MDF file off the hard drive. I'm trying to create a
new database on a different machine using this .MDF file and it appears to
not work. I had shut down SQL on the machine before I copied the file but I
didn't detach it ( didn't have the time and I was trying to explain it to
somebody else. ) So now I have this .MDF file that I can't attach. I'm doing
the following command:
use master
go
CREATE DATABASE BugTracking on (Filename='D:\Program Files\Microsoft SQL
Server\MSSQL\Data\BugTracking.mdf') for attach
go
and I'm getting the following error:
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'BugTracking'. CREATE DATABASE is aborted.
Msg 602, Level 21, State 50, Line 1
Could not find row in sysindexes for database ID 23, object ID 1, index ID
1. Run DBCC CHECKTABLE on sysindexes.
I've also tried to a direct attach deleting the log file and it won't do it.
Anybody have any thoughts?
TIA - Jeff.Can you try sp_attach_single_file_db and see if it works?
See:
http://msdn2.microsoft.com/en-us/library/ms174385(SQL.90).aspx
Adam Machanic
SQL Server MVP
Author, "Expert SQL Server 2005 Development"
http://www.apress.com/book/bookDisplay.html?bID=10220
"Mufasa" <jb@.nowhere.com> wrote in message
news:eH$ODo1sHHA.840@.TK2MSFTNGP03.phx.gbl...
> We had a server that was having all kinds of problems. We finally got it
> booted and I copied the .MDF file off the hard drive. I'm trying to create
> a new database on a different machine using this .MDF file and it appears
> to not work. I had shut down SQL on the machine before I copied the file
> but I didn't detach it ( didn't have the time and I was trying to explain
> it to somebody else. ) So now I have this .MDF file that I can't attach.
> I'm doing the following command:
>
> use master
> go
> CREATE DATABASE BugTracking on (Filename='D:\Program Files\Microsoft SQL
> Server\MSSQL\Data\BugTracking.mdf') for attach
> go
>
> and I'm getting the following error:
>
> Msg 1813, Level 16, State 2, Line 1
> Could not open new database 'BugTracking'. CREATE DATABASE is aborted.
> Msg 602, Level 21, State 50, Line 1
> Could not find row in sysindexes for database ID 23, object ID 1, index ID
> 1. Run DBCC CHECKTABLE on sysindexes.
>
> I've also tried to a direct attach deleting the log file and it won't do
> it.
> Anybody have any thoughts?
> TIA - Jeff.
>|||Sorry everybody - I finally figured out what was wrong - I was trying to
attach the file from a 2005 db into 2000. Once I switched to another server,
it worked fine.
J.
"Adam Machanic" <amachanic@.IHATESPAMgmail.com> wrote in message
news:E95832E9-C1D4-4BC3-B010-6F7079F2AEAF@.microsoft.com...
> Can you try sp_attach_single_file_db and see if it works?
> See:
> http://msdn2.microsoft.com/en-us/library/ms174385(SQL.90).aspx
>
> --
> Adam Machanic
> SQL Server MVP
> Author, "Expert SQL Server 2005 Development"
> http://www.apress.com/book/bookDisplay.html?bID=10220
>
> "Mufasa" <jb@.nowhere.com> wrote in message
> news:eH$ODo1sHHA.840@.TK2MSFTNGP03.phx.gbl...
>

Have an .mdf file but can't seem to attach it.

We had a server that was having all kinds of problems. We finally got it
booted and I copied the .MDF file off the hard drive. I'm trying to create a
new database on a different machine using this .MDF file and it appears to
not work. I had shut down SQL on the machine before I copied the file but I
didn't detach it ( didn't have the time and I was trying to explain it to
somebody else. ) So now I have this .MDF file that I can't attach. I'm doing
the following command:
use master
go
CREATE DATABASE BugTracking on (Filename='D:\Program Files\Microsoft SQL
Server\MSSQL\Data\BugTracking.mdf') for attach
go
and I'm getting the following error:
Msg 1813, Level 16, State 2, Line 1
Could not open new database 'BugTracking'. CREATE DATABASE is aborted.
Msg 602, Level 21, State 50, Line 1
Could not find row in sysindexes for database ID 23, object ID 1, index ID
1. Run DBCC CHECKTABLE on sysindexes.
I've also tried to a direct attach deleting the log file and it won't do it.
Anybody have any thoughts?
TIA - Jeff.Can you try sp_attach_single_file_db and see if it works?
See:
http://msdn2.microsoft.com/en-us/library/ms174385(SQL.90).aspx
Adam Machanic
SQL Server MVP
Author, "Expert SQL Server 2005 Development"
http://www.apress.com/book/bookDisplay.html?bID=10220
"Mufasa" <jb@.nowhere.com> wrote in message
news:eH$ODo1sHHA.840@.TK2MSFTNGP03.phx.gbl...
> We had a server that was having all kinds of problems. We finally got it
> booted and I copied the .MDF file off the hard drive. I'm trying to create
> a new database on a different machine using this .MDF file and it appears
> to not work. I had shut down SQL on the machine before I copied the file
> but I didn't detach it ( didn't have the time and I was trying to explain
> it to somebody else. ) So now I have this .MDF file that I can't attach.
> I'm doing the following command:
>
> use master
> go
> CREATE DATABASE BugTracking on (Filename='D:\Program Files\Microsoft SQL
> Server\MSSQL\Data\BugTracking.mdf') for attach
> go
>
> and I'm getting the following error:
>
> Msg 1813, Level 16, State 2, Line 1
> Could not open new database 'BugTracking'. CREATE DATABASE is aborted.
> Msg 602, Level 21, State 50, Line 1
> Could not find row in sysindexes for database ID 23, object ID 1, index ID
> 1. Run DBCC CHECKTABLE on sysindexes.
>
> I've also tried to a direct attach deleting the log file and it won't do
> it.
> Anybody have any thoughts?
> TIA - Jeff.
>|||Sorry everybody - I finally figured out what was wrong - I was trying to
attach the file from a 2005 db into 2000. Once I switched to another server,
it worked fine.
J.
"Adam Machanic" <amachanic@.IHATESPAMgmail.com> wrote in message
news:E95832E9-C1D4-4BC3-B010-6F7079F2AEAF@.microsoft.com...
> Can you try sp_attach_single_file_db and see if it works?
> See:
> http://msdn2.microsoft.com/en-us/library/ms174385(SQL.90).aspx
>
> --
> Adam Machanic
> SQL Server MVP
> Author, "Expert SQL Server 2005 Development"
> http://www.apress.com/book/bookDisplay.html?bID=10220
>
> "Mufasa" <jb@.nowhere.com> wrote in message
> news:eH$ODo1sHHA.840@.TK2MSFTNGP03.phx.gbl...
>> We had a server that was having all kinds of problems. We finally got it
>> booted and I copied the .MDF file off the hard drive. I'm trying to
>> create a new database on a different machine using this .MDF file and it
>> appears to not work. I had shut down SQL on the machine before I copied
>> the file but I didn't detach it ( didn't have the time and I was trying
>> to explain it to somebody else. ) So now I have this .MDF file that I
>> can't attach. I'm doing the following command:
>>
>> use master
>> go
>> CREATE DATABASE BugTracking on (Filename='D:\Program Files\Microsoft SQL
>> Server\MSSQL\Data\BugTracking.mdf') for attach
>> go
>>
>> and I'm getting the following error:
>>
>> Msg 1813, Level 16, State 2, Line 1
>> Could not open new database 'BugTracking'. CREATE DATABASE is aborted.
>> Msg 602, Level 21, State 50, Line 1
>> Could not find row in sysindexes for database ID 23, object ID 1, index
>> ID 1. Run DBCC CHECKTABLE on sysindexes.
>>
>> I've also tried to a direct attach deleting the log file and it won't do
>> it.
>> Anybody have any thoughts?
>> TIA - Jeff.
>>
>

Hardware Failure, Help w/recover of the msdb database

We lost the hard drive on a dev server. All the databases where backed up
with the exception of Master, Model, and MSDB. I was able to recover the
msdbdata.mdf and msdblog.ldf from the hard drive the crashed.
Is it possible to recover the DTS packages from these files? or am I hosed?
Any help would be greatly appreciated.
Thanks
Kevin
You should be able to attach the old MSDB back to the server.
http://www.databasejournal.com/featu...le.php/3379901
http://www.support.microsoft.com/?id=224071
Andrew J. Kelly SQL MVP
"Kevin" <Kevin@.discussions.microsoft.com> wrote in message
news:0C69CE35-574E-49D5-810E-06854EE51460@.microsoft.com...
> We lost the hard drive on a dev server. All the databases where backed up
> with the exception of Master, Model, and MSDB. I was able to recover the
> msdbdata.mdf and msdblog.ldf from the hard drive the crashed.
> Is it possible to recover the DTS packages from these files? or am I
> hosed?
> Any help would be greatly appreciated.
> Thanks
> Kevin

Hardware Failure, Help w/recover of the msdb database

We lost the hard drive on a dev server. All the databases where backed up
with the exception of Master, Model, and MSDB. I was able to recover the
msdbdata.mdf and msdblog.ldf from the hard drive the crashed.
Is it possible to recover the DTS packages from these files? or am I hosed?
Any help would be greatly appreciated.
Thanks
KevinYou should be able to attach the old MSDB back to the server.
http://www.databasejournal.com/features/mssql/article.php/3379901
http://www.support.microsoft.com/?id=224071
--
Andrew J. Kelly SQL MVP
"Kevin" <Kevin@.discussions.microsoft.com> wrote in message
news:0C69CE35-574E-49D5-810E-06854EE51460@.microsoft.com...
> We lost the hard drive on a dev server. All the databases where backed up
> with the exception of Master, Model, and MSDB. I was able to recover the
> msdbdata.mdf and msdblog.ldf from the hard drive the crashed.
> Is it possible to recover the DTS packages from these files? or am I
> hosed?
> Any help would be greatly appreciated.
> Thanks
> Kevin

Hardware Failure, Help w/recover of the msdb database

We lost the hard drive on a dev server. All the databases where backed up
with the exception of Master, Model, and MSDB. I was able to recover the
msdbdata.mdf and msdblog.ldf from the hard drive the crashed.
Is it possible to recover the DTS packages from these files? or am I hosed?
Any help would be greatly appreciated.
Thanks
KevinYou should be able to attach the old MSDB back to the server.
http://www.databasejournal.com/feat...cle.php/3379901
http://www.support.microsoft.com/?id=224071
Andrew J. Kelly SQL MVP
"Kevin" <Kevin@.discussions.microsoft.com> wrote in message
news:0C69CE35-574E-49D5-810E-06854EE51460@.microsoft.com...
> We lost the hard drive on a dev server. All the databases where backed up
> with the exception of Master, Model, and MSDB. I was able to recover the
> msdbdata.mdf and msdblog.ldf from the hard drive the crashed.
> Is it possible to recover the DTS packages from these files? or am I
> hosed?
> Any help would be greatly appreciated.
> Thanks
> Kevin

Hardware Failure Of Disk Drive

Hello,
While researching potential solutions to expand the disk capacity of our
server I have come across a question that I hope someone in here is able to
answer.
For example a database has got 4 file groups, each with critical data on all
of them. These are directly connected to the server either by internal RAID
config or SAN device. While the database is in operation a transaction is
opened across all file groups, updating and inserting data to all 4. During
this process a RAID card or connection to the SAN fails cutting the
connection to file groups 3 and 4.
The transaction being execured then hits an error (as it cannot continue to
update and read 3 and 4) and goes to rollback transaction. The rollback
however is successful on the file groups 1 and 2 but not on 3 and 4. Thus
potentially leaving data inconsistency.
Am I correct in assuming this? If so, is there any way to combat this
possible situation. Though, I do understand that the likelyhood of a RAID
card or SAN failing is remote the chance is still there.
Thanks
Anubis.If a write fails under these conditions then the database will certainly be
marked Suspect at which point a restore from backup is going to be your best
option. Regular transaction log backups are the simplest way to mitigate
this. Log shipping is an additional option.
On the hardware side, it's possible to mirror over redundant controllers for
RAID or use multiple controllers with failover in a SAN, which will prevent
or limit data loss and downtime in the event of a disk or controller
failure.
David Portas
SQL Server MVP
--|||My understanding is that if it's not committed when the DB restarts it
should rollback the remaining file group 3 and 4 when their connectivity is
back.|||Hello,
This was my understanding also, though, if a database looses connectivity to
a file group would it stop accepting or working with the other files and go
'offline' or does it continue to work with the other files?
"Peter Yao" <peteryao@.NoSPAMhotmail.com> wrote in message
news:%23AR8ACHcFHA.3280@.TK2MSFTNGP09.phx.gbl...
> My understanding is that if it's not committed when the DB restarts it
> should rollback the remaining file group 3 and 4 when their connectivity
> is
> back.
>

Hardware Failure Of Disk Drive

Hello,
While researching potential solutions to expand the disk capacity of our
server I have come across a question that I hope someone in here is able to
answer.
For example a database has got 4 file groups, each with critical data on all
of them. These are directly connected to the server either by internal RAID
config or SAN device. While the database is in operation a transaction is
opened across all file groups, updating and inserting data to all 4. During
this process a RAID card or connection to the SAN fails cutting the
connection to file groups 3 and 4.
The transaction being execured then hits an error (as it cannot continue to
update and read 3 and 4) and goes to rollback transaction. The rollback
however is successful on the file groups 1 and 2 but not on 3 and 4. Thus
potentially leaving data inconsistency.
Am I correct in assuming this? If so, is there any way to combat this
possible situation. Though, I do understand that the likelyhood of a RAID
card or SAN failing is remote the chance is still there.
Thanks
Anubis.
If a write fails under these conditions then the database will certainly be
marked Suspect at which point a restore from backup is going to be your best
option. Regular transaction log backups are the simplest way to mitigate
this. Log shipping is an additional option.
On the hardware side, it's possible to mirror over redundant controllers for
RAID or use multiple controllers with failover in a SAN, which will prevent
or limit data loss and downtime in the event of a disk or controller
failure.
David Portas
SQL Server MVP
|||My understanding is that if it's not committed when the DB restarts it
should rollback the remaining file group 3 and 4 when their connectivity is
back.
|||Hello,
This was my understanding also, though, if a database looses connectivity to
a file group would it stop accepting or working with the other files and go
'offline' or does it continue to work with the other files?
"Peter Yao" <peteryao@.NoSPAMhotmail.com> wrote in message
news:%23AR8ACHcFHA.3280@.TK2MSFTNGP09.phx.gbl...
> My understanding is that if it's not committed when the DB restarts it
> should rollback the remaining file group 3 and 4 when their connectivity
> is
> back.
>

Hardware Failure Of Disk Drive

Hello,
While researching potential solutions to expand the disk capacity of our
server I have come across a question that I hope someone in here is able to
answer.
For example a database has got 4 file groups, each with critical data on all
of them. These are directly connected to the server either by internal RAID
config or SAN device. While the database is in operation a transaction is
opened across all file groups, updating and inserting data to all 4. During
this process a RAID card or connection to the SAN fails cutting the
connection to file groups 3 and 4.
The transaction being execured then hits an error (as it cannot continue to
update and read 3 and 4) and goes to rollback transaction. The rollback
however is successful on the file groups 1 and 2 but not on 3 and 4. Thus
potentially leaving data inconsistency.
Am I correct in assuming this? If so, is there any way to combat this
possible situation. Though, I do understand that the likelyhood of a RAID
card or SAN failing is remote the chance is still there.
Thanks
Anubis.If a write fails under these conditions then the database will certainly be
marked Suspect at which point a restore from backup is going to be your best
option. Regular transaction log backups are the simplest way to mitigate
this. Log shipping is an additional option.
On the hardware side, it's possible to mirror over redundant controllers for
RAID or use multiple controllers with failover in a SAN, which will prevent
or limit data loss and downtime in the event of a disk or controller
failure.
--
David Portas
SQL Server MVP
--|||My understanding is that if it's not committed when the DB restarts it
should rollback the remaining file group 3 and 4 when their connectivity is
back.|||Hello,
This was my understanding also, though, if a database looses connectivity to
a file group would it stop accepting or working with the other files and go
'offline' or does it continue to work with the other files?
"Peter Yao" <peteryao@.NoSPAMhotmail.com> wrote in message
news:%23AR8ACHcFHA.3280@.TK2MSFTNGP09.phx.gbl...
> My understanding is that if it's not committed when the DB restarts it
> should rollback the remaining file group 3 and 4 when their connectivity
> is
> back.
>

Hard Drive trashing After SP2 + KB934458

Hi. Has anyone else had any problem with their SQL Server 2005 going nuts after installing the SP2 + the above hotfix?

We reboot the SQL Server and as soon as SQL receives a command of any sort, the SCSI RAID 5 hard drives light up and start trashing. Therefore every query and even Windows response time is painfully slow or fails to respond. When we look at the Activity Monitor and sp_who2 there is a process running a Select Into from Microsoft SQL Server Management Studio using the sa account from the last database name in our system. So we can't kill the process as it says "Cannot use KILL to kill your own process. Microsoft SQL Server, Error: 6104)".

The last Transact-SQL command from this process is:
create table #tmpDBCCinputbuffer ((Event Type) nvarchar(512),
[Parameters] int, [Event Info] nvarchar(512))
insert into #tmpDBCCinputbuffer exec ('DBCC INPUTBUFFER(56)')
select [Event Info] from #tmpDBCCinputbuffer

The only other issue I should mention is that we had to uninstall and reinstall SQL Server yesterday as SP2 only half installed. The SP2 install log indicated that SQL SP1 wasn't in a good state as we previously (3 months ago) performed an upgrade from Windows 2000 Server to Windows 2003 R2 Server.

Our other 3 Windows 2003 R2 Servers which were a clean install of both Windows and SQL are running fine.

I've been insisting that we do a new clean Windows and SQL install, but the other team members insist that it's been fine until we installed SQL Server SP2.

So can anyone provide and help or evidence to say who is right either way?

Thanks.

It could be a hardware or a controller issue. Please check the system event log or get the hardware guys to confirm that all is fine wiht hardware.

By the way processes that are running are they clocking a lot of IO under SP_WHO2?

Jag

|||It is the same hardware and we've checked the system event log.

The process is Push Merge Replication and there was basically no hard drive I/O. Especially shown in PerfMon.exe

We've fixed the problem now by moving to a Dynamic Pull Merge Subscription Replication model. We've thrown more Drives at the RAID array and reindex the system table MSMerge_Contents and a few other high use tables often and it seems to production ready now.

Hard Drive trashing After SP2 + KB934458

Hi. Has anyone else had any problem with their SQL Server 2005 going nuts after installing the SP2 + the above hotfix?

We reboot the SQL Server and as soon as SQL receives a command of any sort, the SCSI RAID 5 hard drives light up and start trashing. Therefore every query and even Windows response time is painfully slow or fails to respond. When we look at the Activity Monitor and sp_who2 there is a process running a Select Into from Microsoft SQL Server Management Studio using the sa account from the last database name in our system. So we can't kill the process as it says "Cannot use KILL to kill your own process. Microsoft SQL Server, Error: 6104)".

The last Transact-SQL command from this process is:
create table #tmpDBCCinputbuffer ((Event Type) nvarchar(512),
[Parameters] int, [Event Info] nvarchar(512))
insert into #tmpDBCCinputbuffer exec ('DBCC INPUTBUFFER(56)')
select [Event Info] from #tmpDBCCinputbuffer

The only other issue I should mention is that we had to uninstall and reinstall SQL Server yesterday as SP2 only half installed. The SP2 install log indicated that SQL SP1 wasn't in a good state as we previously (3 months ago) performed an upgrade from Windows 2000 Server to Windows 2003 R2 Server.

Our other 3 Windows 2003 R2 Servers which were a clean install of both Windows and SQL are running fine.

I've been insisting that we do a new clean Windows and SQL install, but the other team members insist that it's been fine until we installed SQL Server SP2.

So can anyone provide and help or evidence to say who is right either way?

Thanks.

It could be a hardware or a controller issue. Please check the system event log or get the hardware guys to confirm that all is fine wiht hardware.

By the way processes that are running are they clocking a lot of IO under SP_WHO2?

Jag

|||It is the same hardware and we've checked the system event log.

The process is Push Merge Replication and there was basically no hard drive I/O. Especially shown in PerfMon.exe

We've fixed the problem now by moving to a Dynamic Pull Merge Subscription Replication model. We've thrown more Drives at the RAID array and reindex the system table MSMerge_Contents and a few other high use tables often and it seems to production ready now.

Hard Drive Space and Disk Caching

Dear friends
I have what may be a basic question to most folks here. Does SQL manage disk caching across partitions or hard drives for greatest efficiency
Basically I have a small C drive partition reserved for basic operating systems stuff. All program and data files, including SQL and databases are on the much larger D and E drives. Would there ever be an issue of the C drive not being large enough and causing SQL to slow down or not perform as well
Someone told me that all disk caching happens on the C drive, which doesn't make sense to me. It seems to me that SQL would be smart enough to use other physical drive resources as needed. They are encouraging us to use Partition Magic to expand the size of our C drive (which currently has about 1 Gig available, to be expanded to between 5 and 10 Gig)
Does this seem like good advice?I do not understand what they are saying - by definition caching is =holding data locally for fast access, SQL Server holds data in memory =having read it from disc. What drive letter is utterly irrelevant to it =(and from a data management perspective the whole concept of drive =letters is horrid!)
SQL Server caching is fine across any drive letter - it cares little =about such things. I have one system where C is getting really tight =(due to successive service packs and fixes) but all the SQL server =stuff, pagefile etc is elsewhere and we have noticed no performance =problems.
Mike John
"Kevin" <anonymous@.discussions.microsoft.com> wrote in message =news:4376A82B-AC21-463C-BCDD-B124FE980C98@.microsoft.com...
> Dear friends,
> > I have what may be a basic question to most folks here. Does SQL =manage disk caching across partitions or hard drives for greatest =efficiency?
> > Basically I have a small C drive partition reserved for basic =operating systems stuff. All program and data files, including SQL and =databases are on the much larger D and E drives. Would there ever be an =issue of the C drive not being large enough and causing SQL to slow down =or not perform as well?
> > Someone told me that all disk caching happens on the C drive, which =doesn't make sense to me. It seems to me that SQL would be smart enough =to use other physical drive resources as needed. They are encouraging =us to use Partition Magic to expand the size of our C drive (which =currently has about 1 Gig available, to be expanded to between 5 and 10 =Gig).
> > Does this seem like good advice?|||Kevin,
First off sql servers cache is a memory based cache not a disk one. The
cache your thinking of is the OS cache or virtual memory. A properly tuned
Sql Server will not use this cache at all. And yes it is usually on the c:
drive. Second it sounds like your drives are all logical drives on the same
physical hard drive. If this is the case it doesn't matter since it is all
the same physical drive. Having multiple logical partitions is more of a
hindrance than a help in that case.
--
Andrew J. Kelly
SQL Server MVP
"Kevin" <anonymous@.discussions.microsoft.com> wrote in message
news:4376A82B-AC21-463C-BCDD-B124FE980C98@.microsoft.com...
> Dear friends,
> I have what may be a basic question to most folks here. Does SQL manage
disk caching across partitions or hard drives for greatest efficiency?
> Basically I have a small C drive partition reserved for basic operating
systems stuff. All program and data files, including SQL and databases are
on the much larger D and E drives. Would there ever be an issue of the C
drive not being large enough and causing SQL to slow down or not perform as
well?
> Someone told me that all disk caching happens on the C drive, which
doesn't make sense to me. It seems to me that SQL would be smart enough to
use other physical drive resources as needed. They are encouraging us to
use Partition Magic to expand the size of our C drive (which currently has
about 1 Gig available, to be expanded to between 5 and 10 Gig).
> Does this seem like good advice?|||Dear Andriew and Mike,
Thank you both for your responses. It seems to me, from them, that we do not have an immediate need to re-partition our hard drive.
I did wonder what you had in mind Andrew, though, when you said:
"Having multiple logical partitions is more of a hindrance than a help in that case."
Pardon my naivete. Thanks!
In Peace,
K.|||Two things that I see often. One is that by having several logical drives
it tends to give the impression there are multiple physical drives. For
someone not familiar with the hardware they may make assumptions that are
wrong based on this. The other is that by having multiple logical
partitions you effectively limit how much space you have in each. Where as
if it was all one logical partition you don't have to worry about running
out of room until you hit the disk limit, not the partition limit. Hope
that helps.
--
Andrew J. Kelly
SQL Server MVP
"Kevin" <anonymous@.discussions.microsoft.com> wrote in message
news:41D04118-B9C2-45BD-8D81-1179187976F6@.microsoft.com...
> Dear Andriew and Mike,
> Thank you both for your responses. It seems to me, from them, that we do
not have an immediate need to re-partition our hard drive.
> I did wonder what you had in mind Andrew, though, when you said:
> "Having multiple logical partitions is more of a hindrance than a help in
that case."
> Pardon my naivete. Thanks!
> In Peace,
> K.
>

Hard Drive Space and Disk Caching

Dear friends,
I have what may be a basic question to most folks here. Does SQL manage dis
k caching across partitions or hard drives for greatest efficiency?
Basically I have a small C drive partition reserved for basic operating syst
ems stuff. All program and data files, including SQL and databases are on t
he much larger D and E drives. Would there ever be an issue of the C drive
not being large enough and
causing SQL to slow down or not perform as well?
Someone told me that all disk caching happens on the C drive, which doesn't
make sense to me. It seems to me that SQL would be smart enough to use othe
r physical drive resources as needed. They are encouraging us to use Partit
ion Magic to expand the siz
e of our C drive (which currently has about 1 Gig available, to be expanded
to between 5 and 10 Gig).
Does this seem like good advice?I do not understand what they are saying - by definition caching is =
holding data locally for fast access, SQL Server holds data in memory =
having read it from disc. What drive letter is utterly irrelevant to it =
(and from a data management perspective the whole concept of drive =
letters is horrid!)=20
SQL Server caching is fine across any drive letter - it cares little =
about such things. I have one system where C is getting really tight =
(due to successive service packs and fixes) but all the SQL server =
stuff, pagefile etc is elsewhere and we have noticed no performance =
problems.
Mike John
"Kevin" <anonymous@.discussions.microsoft.com> wrote in message =
news:4376A82B-AC21-463C-BCDD-B124FE980C98@.microsoft.com...
> Dear friends,
>=20
> I have what may be a basic question to most folks here. Does SQL =
manage disk caching across partitions or hard drives for greatest =
efficiency?
>=20
> Basically I have a small C drive partition reserved for basic =
operating systems stuff. All program and data files, including SQL and =
databases are on the much larger D and E drives. Would there ever be an =
issue of the C drive not being large enough and causing SQL to slow down =
or not perform as well?
>=20
> Someone told me that all disk caching happens on the C drive, which =
doesn't make sense to me. It seems to me that SQL would be smart enough =
to use other physical drive resources as needed. They are encouraging =
us to use Partition Magic to expand the size of our C drive (which =
currently has about 1 Gig available, to be expanded to between 5 and 10 =
Gig).
>=20
> Does this seem like good advice?|||Kevin,
First off sql servers cache is a memory based cache not a disk one. The
cache your thinking of is the OS cache or virtual memory. A properly tuned
Sql Server will not use this cache at all. And yes it is usually on the c:
drive. Second it sounds like your drives are all logical drives on the same
physical hard drive. If this is the case it doesn't matter since it is all
the same physical drive. Having multiple logical partitions is more of a
hindrance than a help in that case.
Andrew J. Kelly
SQL Server MVP
"Kevin" <anonymous@.discussions.microsoft.com> wrote in message
news:4376A82B-AC21-463C-BCDD-B124FE980C98@.microsoft.com...
> Dear friends,
> I have what may be a basic question to most folks here. Does SQL manage
disk caching across partitions or hard drives for greatest efficiency?
> Basically I have a small C drive partition reserved for basic operating
systems stuff. All program and data files, including SQL and databases are
on the much larger D and E drives. Would there ever be an issue of the C
drive not being large enough and causing SQL to slow down or not perform as
well?
> Someone told me that all disk caching happens on the C drive, which
doesn't make sense to me. It seems to me that SQL would be smart enough to
use other physical drive resources as needed. They are encouraging us to
use Partition Magic to expand the size of our C drive (which currently has
about 1 Gig available, to be expanded to between 5 and 10 Gig).
> Does this seem like good advice?|||Dear Andriew and Mike,
Thank you both for your responses. It seems to me, from them, that we do no
t have an immediate need to re-partition our hard drive.
I did wonder what you had in mind Andrew, though, when you said:
"Having multiple logical partitions is more of a hindrance than a help in th
at case."
Pardon my naivete. Thanks!
In Peace,
K.|||Two things that I see often. One is that by having several logical drives
it tends to give the impression there are multiple physical drives. For
someone not familiar with the hardware they may make assumptions that are
wrong based on this. The other is that by having multiple logical
partitions you effectively limit how much space you have in each. Where as
if it was all one logical partition you don't have to worry about running
out of room until you hit the disk limit, not the partition limit. Hope
that helps.
Andrew J. Kelly
SQL Server MVP
"Kevin" <anonymous@.discussions.microsoft.com> wrote in message
news:41D04118-B9C2-45BD-8D81-1179187976F6@.microsoft.com...
> Dear Andriew and Mike,
> Thank you both for your responses. It seems to me, from them, that we do
not have an immediate need to re-partition our hard drive.
> I did wonder what you had in mind Andrew, though, when you said:
> "Having multiple logical partitions is more of a hindrance than a help in
that case."
> Pardon my naivete. Thanks!
> In Peace,
> K.
>

Hard Drive Crashed. master & user db mdf & ldf files lost

Hello.

One of our hard drives has crashed and as a result we have lost our master mdf/ldf & user db mdf/ldf files. It's not that a critical system by any means, but if the hard drive crashes and the master mdf/ldf files & user db mdf/ldf are lost, is there any way of restoring the system?

I'm thinking we probably need to re-install Enterprise Manager completely, and re-install the user db from a backup.

Any advice/suggestions would be much appreciated.

Thanks in advance,If the disks are toast, then you have to restore from your backups. When you have the hardware and O/S back to where they need to be, install SQL Server with any required service packs/patches, then restore the master database (see BOL for instructions), then restore the user databases.

Hard drive crashed but MDF/LDF on drive D:

SQL 7.0/Server 2000
The c: drive crashed;
the MDF and LDF files were on drive D:
When a new hard drive is installed with the new OS and
SQL 7.0 installed on it...is there a way to "attach" to
the MDF and LDF files? or are they lost?
Thanks,
Don
with SQL7 and/or SQL 2000
you can try sp_attach_db
PS. usually better to perform sp_detach_db but you had no choice in this
instance :-)
hope this works.
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:086001c4f832$20813b50$a601280a@.phx.gbl...
> SQL 7.0/Server 2000
> The c: drive crashed;
> the MDF and LDF files were on drive D:
> When a new hard drive is installed with the new OS and
> SQL 7.0 installed on it...is there a way to "attach" to
> the MDF and LDF files? or are they lost?
> Thanks,
> Don
>
|||sp_attach_db is the first choice but if you have issues this may help:
http://www.sqlservercentral.com/scri...p?scriptid=599
Restoring a .mdf
http://www.support.microsoft.com/?id=314546 Moving DB's between Servers
http://www.support.microsoft.com/?id=224071 Moving SQL Server Databases
to a New Location with Detach/Attach
http://support.microsoft.com/?id=221465 Using WITH MOVE in a
Restore
http://www.support.microsoft.com/?id=246133 How To Transfer Logins and
Passwords Between SQL Servers
http://www.support.microsoft.com/?id=298897 Mapping Logins & SIDs after a
Restore
http://www.dbmaint.com/SyncSqlLogins.asp Utility to map logins to
users
http://www.support.microsoft.com/?id=168001 User Logon and/or Permission
Errors After Restoring Dump
http://www.support.microsoft.com/?id=240872 How to Resolve Permission
Issues When a Database Is Moved Between SQL Servers
http://www.support.microsoft.com/?id=307775 Disaster Recovery Articles
for SQL Server
Andrew J. Kelly SQL MVP
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:086001c4f832$20813b50$a601280a@.phx.gbl...
> SQL 7.0/Server 2000
> The c: drive crashed;
> the MDF and LDF files were on drive D:
> When a new hard drive is installed with the new OS and
> SQL 7.0 installed on it...is there a way to "attach" to
> the MDF and LDF files? or are they lost?
> Thanks,
> Don
>

Hard drive crashed but MDF/LDF on drive D:

SQL 7.0/Server 2000
The c: drive crashed;
the MDF and LDF files were on drive D:
When a new hard drive is installed with the new OS and
SQL 7.0 installed on it...is there a way to "attach" to
the MDF and LDF files? or are they lost?
Thanks,
Donwith SQL7 and/or SQL 2000
you can try sp_attach_db
PS. usually better to perform sp_detach_db but you had no choice in this
instance :-)
hope this works.
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:086001c4f832$20813b50$a601280a@.phx.gbl...
> SQL 7.0/Server 2000
> The c: drive crashed;
> the MDF and LDF files were on drive D:
> When a new hard drive is installed with the new OS and
> SQL 7.0 installed on it...is there a way to "attach" to
> the MDF and LDF files? or are they lost?
> Thanks,
> Don
>|||sp_attach_db is the first choice but if you have issues this may help:
http://www.sqlservercentral.com/scr...sp?scriptid=599
Restoring a .mdf
http://www.support.microsoft.com/?id=314546 Moving DB's between Servers
http://www.support.microsoft.com/?id=224071 Moving SQL Server Databases
to a New Location with Detach/Attach
http://support.microsoft.com/?id=221465 Using WITH MOVE in a
Restore
http://www.support.microsoft.com/?id=246133 How To Transfer Logins and
Passwords Between SQL Servers
http://www.support.microsoft.com/?id=298897 Mapping Logins & SIDs after a
Restore
http://www.dbmaint.com/SyncSqlLogins.asp Utility to map logins to
users
http://www.support.microsoft.com/?id=168001 User Logon and/or Permission
Errors After Restoring Dump
http://www.support.microsoft.com/?id=240872 How to Resolve Permission
Issues When a Database Is Moved Between SQL Servers
http://www.support.microsoft.com/?id=307775 Disaster Recovery Articles
for SQL Server
Andrew J. Kelly SQL MVP
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:086001c4f832$20813b50$a601280a@.phx.gbl...
> SQL 7.0/Server 2000
> The c: drive crashed;
> the MDF and LDF files were on drive D:
> When a new hard drive is installed with the new OS and
> SQL 7.0 installed on it...is there a way to "attach" to
> the MDF and LDF files? or are they lost?
> Thanks,
> Don
>

Hard drive crashed but MDF/LDF on drive D:

SQL 7.0/Server 2000
The c: drive crashed;
the MDF and LDF files were on drive D:
When a new hard drive is installed with the new OS and
SQL 7.0 installed on it...is there a way to "attach" to
the MDF and LDF files? or are they lost?
Thanks,
Donwith SQL7 and/or SQL 2000
you can try sp_attach_db
PS. usually better to perform sp_detach_db but you had no choice in this
instance :-)
hope this works.
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:086001c4f832$20813b50$a601280a@.phx.gbl...
> SQL 7.0/Server 2000
> The c: drive crashed;
> the MDF and LDF files were on drive D:
> When a new hard drive is installed with the new OS and
> SQL 7.0 installed on it...is there a way to "attach" to
> the MDF and LDF files? or are they lost?
> Thanks,
> Don
>|||sp_attach_db is the first choice but if you have issues this may help:
http://www.sqlservercentral.com/scripts/scriptdetails.asp?scriptid=599
Restoring a .mdf
http://www.support.microsoft.com/?id=314546 Moving DB's between Servers
http://www.support.microsoft.com/?id=224071 Moving SQL Server Databases
to a New Location with Detach/Attach
http://support.microsoft.com/?id=221465 Using WITH MOVE in a
Restore
http://www.support.microsoft.com/?id=246133 How To Transfer Logins and
Passwords Between SQL Servers
http://www.support.microsoft.com/?id=298897 Mapping Logins & SIDs after a
Restore
http://www.dbmaint.com/SyncSqlLogins.asp Utility to map logins to
users
http://www.support.microsoft.com/?id=168001 User Logon and/or Permission
Errors After Restoring Dump
http://www.support.microsoft.com/?id=240872 How to Resolve Permission
Issues When a Database Is Moved Between SQL Servers
http://www.support.microsoft.com/?id=307775 Disaster Recovery Articles
for SQL Server
Andrew J. Kelly SQL MVP
"Don" <anonymous@.discussions.microsoft.com> wrote in message
news:086001c4f832$20813b50$a601280a@.phx.gbl...
> SQL 7.0/Server 2000
> The c: drive crashed;
> the MDF and LDF files were on drive D:
> When a new hard drive is installed with the new OS and
> SQL 7.0 installed on it...is there a way to "attach" to
> the MDF and LDF files? or are they lost?
> Thanks,
> Don
>