Dropping a file in a filegroup that does not exist.

Hi,
I moved a database from an older sql box to one of our new servers. One of
the files in the prmiary file group was not moved and the server was wiped...
the filename is sysft_ix_STS_neo_1414639615. Everytime I try to do a backup
of that database I get a "file or firegroup is not online..." error message
and SQL won't let me drop it because it does not exist. Can anyone help me
out?Hi Henry
If there was data in this filegroup then you would have to resort to your
last backup.
John
"Henry" wrote:
> Hi,
> I moved a database from an older sql box to one of our new servers. One of
> the files in the prmiary file group was not moved and the server was wiped...
> the filename is sysft_ix_STS_neo_1414639615. Everytime I try to do a backup
> of that database I get a "file or firegroup is not online..." error message
> and SQL won't let me drop it because it does not exist. Can anyone help me
> out?|||I'm pretty certain this is the full text index and that rebuilding or removing full-text indexing
would solve this. This is what I recall from earlier post with the same problem.
--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:7E297789-FEFB-41D9-BF17-90BF96129198@.microsoft.com...
> Hi Henry
> If there was data in this filegroup then you would have to resort to your
> last backup.
> John
> "Henry" wrote:
>> Hi,
>> I moved a database from an older sql box to one of our new servers. One of
>> the files in the prmiary file group was not moved and the server was wiped...
>> the filename is sysft_ix_STS_neo_1414639615. Everytime I try to do a backup
>> of that database I get a "file or firegroup is not online..." error message
>> and SQL won't let me drop it because it does not exist. Can anyone help me
>> out?|||Hi Tibor
You are probably right! sp_help_fulltext_catalogs might verify this!
John
"Tibor Karaszi" wrote:
> I'm pretty certain this is the full text index and that rebuilding or removing full-text indexing
> would solve this. This is what I recall from earlier post with the same problem.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:7E297789-FEFB-41D9-BF17-90BF96129198@.microsoft.com...
> > Hi Henry
> >
> > If there was data in this filegroup then you would have to resort to your
> > last backup.
> >
> > John
> >
> > "Henry" wrote:
> >
> >> Hi,
> >>
> >> I moved a database from an older sql box to one of our new servers. One of
> >> the files in the prmiary file group was not moved and the server was wiped...
> >> the filename is sysft_ix_STS_neo_1414639615. Everytime I try to do a backup
> >> of that database I get a "file or firegroup is not online..." error message
> >> and SQL won't let me drop it because it does not exist. Can anyone help me
> >> out?
>

Dropping a file in a filegroup that does not exist.

Hi,
I moved a database from an older sql box to one of our new servers. One of
the files in the prmiary file group was not moved and the server was wiped..
.
the filename is sysft_ix_STS_neo_1414639615. Everytime I try to do a backup
of that database I get a "file or firegroup is not online..." error message
and SQL won't let me drop it because it does not exist. Can anyone help me
out?Hi Henry
If there was data in this filegroup then you would have to resort to your
last backup.
John
"Henry" wrote:

> Hi,
> I moved a database from an older sql box to one of our new servers. One o
f
> the files in the prmiary file group was not moved and the server was wiped
..
> the filename is sysft_ix_STS_neo_1414639615. Everytime I try to do a back
up
> of that database I get a "file or firegroup is not online..." error messag
e
> and SQL won't let me drop it because it does not exist. Can anyone help m
e
> out?|||Hi Henry
If there was data in this filegroup then you would have to resort to your
last backup.
John
"Henry" wrote:

> Hi,
> I moved a database from an older sql box to one of our new servers. One o
f
> the files in the prmiary file group was not moved and the server was wiped
..
> the filename is sysft_ix_STS_neo_1414639615. Everytime I try to do a back
up
> of that database I get a "file or firegroup is not online..." error messag
e
> and SQL won't let me drop it because it does not exist. Can anyone help m
e
> out?|||I'm pretty certain this is the full text index and that rebuilding or removi
ng full-text indexing
would solve this. This is what I recall from earlier post with the same prob
lem.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:7E297789-FEFB-41D9-BF17-90BF96129198@.microsoft.com...[vbcol=seagreen]
> Hi Henry
> If there was data in this filegroup then you would have to resort to your
> last backup.
> John
> "Henry" wrote:
>|||Hi Tibor
You are probably right! sp_help_fulltext_catalogs might verify this!
John
"Tibor Karaszi" wrote:

> I'm pretty certain this is the full text index and that rebuilding or remo
ving full-text indexing
> would solve this. This is what I recall from earlier post with the same pr
oblem.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:7E297789-FEFB-41D9-BF17-90BF96129198@.microsoft.com...
>|||I'm pretty certain this is the full text index and that rebuilding or removi
ng full-text indexing
would solve this. This is what I recall from earlier post with the same prob
lem.
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://www.solidqualitylearning.com/
"John Bell" <jbellnewsposts@.hotmail.com> wrote in message
news:7E297789-FEFB-41D9-BF17-90BF96129198@.microsoft.com...[vbcol=seagreen]
> Hi Henry
> If there was data in this filegroup then you would have to resort to your
> last backup.
> John
> "Henry" wrote:
>|||Hi Tibor
You are probably right! sp_help_fulltext_catalogs might verify this!
John
"Tibor Karaszi" wrote:

> I'm pretty certain this is the full text index and that rebuilding or remo
ving full-text indexing
> would solve this. This is what I recall from earlier post with the same pr
oblem.
> --
> Tibor Karaszi, SQL Server MVP
> http://www.karaszi.com/sqlserver/default.asp
> http://www.solidqualitylearning.com/
>
> "John Bell" <jbellnewsposts@.hotmail.com> wrote in message
> news:7E297789-FEFB-41D9-BF17-90BF96129198@.microsoft.com...
>

Droping Log File

I have two transaction log files, one on C drive and other on D drive. I want to drop the file from that database that is on C drive. Can anyone help me out on this with complete syntax.

I have taken a down time of one and half hour to accomplish this task

Here is what think

Take a full database backup
Take transaction log backup
Shrinkfile using DBCC with truncateonly option
emptyfile using dbcc or drop file using alter database remove

thanks for your input guys

RomeYou can do it all on EM. But the most important thing is to do a checkpoint to make sure everything is on disk, and then do a log backup. The log file should be empty, and you should be able to delete the log file from EM.

dropdown menu in sql reporting

Is it possible in SQL Reporting 2005 to have dropdown menu(eg..on mouseover list of static menu appears from which i can navigate to other rdl files while passing all parameters) ..

Do you mean in the parameter pane or within the report ?

Jens K. Suessmeyer.

http://www.sqlserver2005.de

|||

I mean within the report..
As for now on i made one horizontal table and below it vertical menutable..now on form load and other event of the form i pass in navigation parqameter VerticaltableDisplay="N" and only in one event when Cell of horizontal table on top I pass parmeter =IIF(VerticaltableDisplay="Y","N","Y")

and in visiblity property of vertical table gave a condition =IIF(VerticaltableDisplay="Y",Display,Hide)*

It is working for click event ok but how can i do for mouseover event...

as if once clicked on report its visible and if there is no other even and we export to different format the verticaltable is visible

|||Javascript is very restricted in Reporting Services, I guess you cannot use the mouseover events here.

HTH, Jens K. Suessmeyer.

-
http://www.sqlserver2005.de
-

Driver Install Location

I have read most of the documentation on installing the JDBC driver and need
a bit of clarification on what and where files gets installed.
First: Am I correct to assume that installation takes place on the client
machine and than NO files are actually installed on the server hosting SQL
Server?
Second: If the JRE is installed on the client, is it only the class jars,
msutil.jar, mssqlserver.jar, msbase.jar that are responsible for enabling the
JDBC connection.
Kind regards for any reply
| Thread-Topic: Driver Install Location
| thread-index: AcS7ky47eyc/czQMQSKYX1iOSRQzOQ==
| X-WBNR-Posting-Host: 24.169.110.115
| From: "=?Utf-8?B?Q2hyaXM=?=" <Chris@.discussions.microsoft.com>
| Subject: Driver Install Location
| Date: Tue, 26 Oct 2004 12:37:08 -0700
| Lines: 12
| Message-ID: <E20ADC31-1528-4F55-8A5A-C3FE05250257@.microsoft.com>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.sqlserver.jdbcdriver
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
| Path: cpmsftngxa10.phx.gbl!TK2MSFTNGXA03.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.sqlserver.jdbcdriver:6425
| X-Tomcat-NG: microsoft.public.sqlserver.jdbcdriver
|
| I have read most of the documentation on installing the JDBC driver and
need
| a bit of clarification on what and where files gets installed.
|
| First: Am I correct to assume that installation takes place on the client
| machine and than NO files are actually installed on the server hosting
SQL
| Server?
|
| Second: If the JRE is installed on the client, is it only the class jars,
| msutil.jar, mssqlserver.jar, msbase.jar that are responsible for enabling
the
| JDBC connection.
|
| Kind regards for any reply
|
Hello,
The Microsoft JDBC driver is a client installation. You will need to add
the three .jar files to your CLASSPATH on the client machine as well. If
you are using an application server, then the .jar files will need to be
installed on this machine. The installation location and CLASSPATH
configuration steps vary depending on the app server you are using.
The only server component that you may need is the sqljdbc.dll file, which
enables JTA support (transactions). If your application will require this,
then you will need to copy this file from C:\program files\Microsoft SQL
Server 2000 Driver for JDBC\SQLServer JTA\ (or C:\program files\Microsoft
SQL Server 2000 Driver for JDBC\SQLServer JTA 64-bit\ in the case of 64-bit
machines) into the C:\program files\Microsoft SQL Server\MSSQL\Binn\
directory of your SQL Server 2000 installation. Then, you must run the
instjdbc.sql script from C:\program files\Microsoft SQL Server 2000 Driver
for JDBC\SQLServer JTA\ to install the extended stored procedures. You can
use Query Analyzer or osql.exe to run the script.
The JDBC documentation (.pdf) describes the CLASSPATH configuration and JTA
installation in more detail. Look for the following topics:
"Setting the CLASSPATH"
"Installing Stored Procedures for JTA"
Carb Simien, MCSE MCDBA MCAD
Microsoft Developer Support - Web Data
Please reply only to the newsgroups.
This posting is provided "AS IS" with no warranties, and confers no rights.
Are you secure? For information about the Strategic Technology Protection
Program and to order your FREE Security Tool Kit, please visit
http://www.microsoft.com/security.

Drive lost - log files were on that drive - wondering about option

I've got a customer who re-booted their SQL server (SQL 2000) and when it
came up the F: drive - with all the log files - was gone.
They are going to attempt to get the F: drive back on-line - hopefully long
enough to detach the DB's and copy the LOG files to another drive.
If that does not work - we see two options at this moment.
We have backups, including TRANSACTION log backups every hour - last one was
at 3:00 pm today. The server was re-booted just before the 4:00 cycle - so
we have about 50 minutes of "unknown" work that was not backed up. We
realize we could restore all the DB's from the backup/transaction log backups
at get us back to 3:00 pm.
Other option would be to attempt to start the DB's with new empty logs. Not
so comfortable with this option. How do we check that the DB's were
closed/shutdown properly when the server rebooted - so we know that we aren't
going to be missing rollback/commit operations.
Thanks for any help you can offer - I might not be back till Sunday
afternoon to check this thread - but only have till Tuesday AM to get the box
back up and running.If you can't get your log files back, I suggest you first copy all data
files elsewhere for safe keeping. Then try to attach the databases. If a
database is at a consistent state and has a single log file, SQL Server will
recreate the log and no data will be lost.
For databases that cannot be attached, I suggest you restore from database
and transaction log backups. You can also salvage what you can for the lost
50 minutes by rebuilding logs from the copied data files, running DBCCs and
reconciling. However, you will not have logical or physical data integrity
after recreating logs for a 'dirty' database. You are wise to be
uncomfortable with using those databases as the live version.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:0B9A38A2-067F-4101-9BE5-95D6F59759DC@.microsoft.com...
> I've got a customer who re-booted their SQL server (SQL 2000) and when it
> came up the F: drive - with all the log files - was gone.
> They are going to attempt to get the F: drive back on-line - hopefully
> long
> enough to detach the DB's and copy the LOG files to another drive.
> If that does not work - we see two options at this moment.
> We have backups, including TRANSACTION log backups every hour - last one
> was
> at 3:00 pm today. The server was re-booted just before the 4:00 cycle -
> so
> we have about 50 minutes of "unknown" work that was not backed up. We
> realize we could restore all the DB's from the backup/transaction log
> backups
> at get us back to 3:00 pm.
> Other option would be to attempt to start the DB's with new empty logs.
> Not
> so comfortable with this option. How do we check that the DB's were
> closed/shutdown properly when the server rebooted - so we know that we
> aren't
> going to be missing rollback/commit operations.
> Thanks for any help you can offer - I might not be back till Sunday
> afternoon to check this thread - but only have till Tuesday AM to get the
> box
> back up and running.|||Dan - thanks for the response - kind of confirmed what I was expecting.
We do only have single LOG files...
How does the server know that the DB is in a consistent state? The server
was shutdown with the log files still accessible - it was the re-boot moment
that the F: drive disappered. If I can guarantee that the DB received all
logged data during shutdown (is that possible?) - then I can use these DB's
with empty logs - right?
Several of the DB's are our design - we have APPCONNECT tables that will
tell me who was connected and what time they jumped in. We also have TDATE
columns in all our tables that indicate GETDATE() timestamps of last
INSERT/UPDATE of the row.
Some of the DB's are not ours - so I'm going to have less ability to even do
a reconciliation between RESTORED DB and REATTACHED-WITH-EMPTY LOG DB's...
Thanks again!
"Dan Guzman" wrote:
> If you can't get your log files back, I suggest you first copy all data
> files elsewhere for safe keeping. Then try to attach the databases. If a
> database is at a consistent state and has a single log file, SQL Server will
> recreate the log and no data will be lost.
> For databases that cannot be attached, I suggest you restore from database
> and transaction log backups. You can also salvage what you can for the lost
> 50 minutes by rebuilding logs from the copied data files, running DBCCs and
> reconciling. However, you will not have logical or physical data integrity
> after recreating logs for a 'dirty' database. You are wise to be
> uncomfortable with using those databases as the live version.
> --
> Hope this helps.
> Dan Guzman
> SQL Server MVP
> "Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
> news:0B9A38A2-067F-4101-9BE5-95D6F59759DC@.microsoft.com...
> > I've got a customer who re-booted their SQL server (SQL 2000) and when it
> > came up the F: drive - with all the log files - was gone.
> >
> > They are going to attempt to get the F: drive back on-line - hopefully
> > long
> > enough to detach the DB's and copy the LOG files to another drive.
> >
> > If that does not work - we see two options at this moment.
> >
> > We have backups, including TRANSACTION log backups every hour - last one
> > was
> > at 3:00 pm today. The server was re-booted just before the 4:00 cycle -
> > so
> > we have about 50 minutes of "unknown" work that was not backed up. We
> > realize we could restore all the DB's from the backup/transaction log
> > backups
> > at get us back to 3:00 pm.
> >
> > Other option would be to attempt to start the DB's with new empty logs.
> > Not
> > so comfortable with this option. How do we check that the DB's were
> > closed/shutdown properly when the server rebooted - so we know that we
> > aren't
> > going to be missing rollback/commit operations.
> >
> > Thanks for any help you can offer - I might not be back till Sunday
> > afternoon to check this thread - but only have till Tuesday AM to get the
> > box
> > back up and running.
>
>|||> If I can guarantee that the DB received all
> logged data during shutdown (is that possible?) - then I can use these
> DB's
> with empty logs - right?
I don't recall the exact implementation details but the primary data file
contains information indicating whether or not a database was cleanly
shutdown. SQL Server checks this and will not create an new log file during
the attach unless it is safe to do so.
So the way to check it to try it - detach the suspect databases and then
attempt to attach specifying only the primary data file. If the shutdown
was clean, SQL Server will create a new log and you are good to go without
issues. If you get errors because the database shutdown wasn't clean, you
should restore from backups and accept the 50 minute data loss.
It's up to you whether you should go through the extra effort salvage and
data.
--
Hope this helps.
Dan Guzman
SQL Server MVP
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:3FF3320E-7B51-4F0F-9F3F-806B24A9E7DB@.microsoft.com...
> Dan - thanks for the response - kind of confirmed what I was expecting.
> We do only have single LOG files...
> How does the server know that the DB is in a consistent state? The server
> was shutdown with the log files still accessible - it was the re-boot
> moment
> that the F: drive disappered. If I can guarantee that the DB received all
> logged data during shutdown (is that possible?) - then I can use these
> DB's
> with empty logs - right?
> Several of the DB's are our design - we have APPCONNECT tables that will
> tell me who was connected and what time they jumped in. We also have
> TDATE
> columns in all our tables that indicate GETDATE() timestamps of last
> INSERT/UPDATE of the row.
> Some of the DB's are not ours - so I'm going to have less ability to even
> do
> a reconciliation between RESTORED DB and REATTACHED-WITH-EMPTY LOG DB's...
> Thanks again!
> "Dan Guzman" wrote:
>> If you can't get your log files back, I suggest you first copy all data
>> files elsewhere for safe keeping. Then try to attach the databases. If
>> a
>> database is at a consistent state and has a single log file, SQL Server
>> will
>> recreate the log and no data will be lost.
>> For databases that cannot be attached, I suggest you restore from
>> database
>> and transaction log backups. You can also salvage what you can for the
>> lost
>> 50 minutes by rebuilding logs from the copied data files, running DBCCs
>> and
>> reconciling. However, you will not have logical or physical data
>> integrity
>> after recreating logs for a 'dirty' database. You are wise to be
>> uncomfortable with using those databases as the live version.
>> --
>> Hope this helps.
>> Dan Guzman
>> SQL Server MVP
>> "Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
>> news:0B9A38A2-067F-4101-9BE5-95D6F59759DC@.microsoft.com...
>> > I've got a customer who re-booted their SQL server (SQL 2000) and when
>> > it
>> > came up the F: drive - with all the log files - was gone.
>> >
>> > They are going to attempt to get the F: drive back on-line - hopefully
>> > long
>> > enough to detach the DB's and copy the LOG files to another drive.
>> >
>> > If that does not work - we see two options at this moment.
>> >
>> > We have backups, including TRANSACTION log backups every hour - last
>> > one
>> > was
>> > at 3:00 pm today. The server was re-booted just before the 4:00
>> > cycle -
>> > so
>> > we have about 50 minutes of "unknown" work that was not backed up. We
>> > realize we could restore all the DB's from the backup/transaction log
>> > backups
>> > at get us back to 3:00 pm.
>> >
>> > Other option would be to attempt to start the DB's with new empty logs.
>> > Not
>> > so comfortable with this option. How do we check that the DB's were
>> > closed/shutdown properly when the server rebooted - so we know that we
>> > aren't
>> > going to be missing rollback/commit operations.
>> >
>> > Thanks for any help you can offer - I might not be back till Sunday
>> > afternoon to check this thread - but only have till Tuesday AM to get
>> > the
>> > box
>> > back up and running.
>>

Drive lost - log files were on that drive - wondering about option

I've got a customer who re-booted their SQL server (SQL 2000) and when it
came up the F: drive - with all the log files - was gone.
They are going to attempt to get the F: drive back on-line - hopefully long
enough to detach the DB's and copy the LOG files to another drive.
If that does not work - we see two options at this moment.
We have backups, including TRANSACTION log backups every hour - last one was
at 3:00 pm today. The server was re-booted just before the 4:00 cycle - so
we have about 50 minutes of "unknown" work that was not backed up. We
realize we could restore all the DB's from the backup/transaction log backup
s
at get us back to 3:00 pm.
Other option would be to attempt to start the DB's with new empty logs. Not
so comfortable with this option. How do we check that the DB's were
closed/shutdown properly when the server rebooted - so we know that we aren'
t
going to be missing rollback/commit operations.
Thanks for any help you can offer - I might not be back till Sunday
afternoon to check this thread - but only have till Tuesday AM to get the bo
x
back up and running.If you can't get your log files back, I suggest you first copy all data
files elsewhere for safe keeping. Then try to attach the databases. If a
database is at a consistent state and has a single log file, SQL Server will
recreate the log and no data will be lost.
For databases that cannot be attached, I suggest you restore from database
and transaction log backups. You can also salvage what you can for the lost
50 minutes by rebuilding logs from the copied data files, running DBCCs and
reconciling. However, you will not have logical or physical data integrity
after recreating logs for a 'dirty' database. You are wise to be
uncomfortable with using those databases as the live version.
Hope this helps.
Dan Guzman
SQL Server MVP
"Steve Z" <SteveZ@.discussions.microsoft.com> wrote in message
news:0B9A38A2-067F-4101-9BE5-95D6F59759DC@.microsoft.com...
> I've got a customer who re-booted their SQL server (SQL 2000) and when it
> came up the F: drive - with all the log files - was gone.
> They are going to attempt to get the F: drive back on-line - hopefully
> long
> enough to detach the DB's and copy the LOG files to another drive.
> If that does not work - we see two options at this moment.
> We have backups, including TRANSACTION log backups every hour - last one
> was
> at 3:00 pm today. The server was re-booted just before the 4:00 cycle -
> so
> we have about 50 minutes of "unknown" work that was not backed up. We
> realize we could restore all the DB's from the backup/transaction log
> backups
> at get us back to 3:00 pm.
> Other option would be to attempt to start the DB's with new empty logs.
> Not
> so comfortable with this option. How do we check that the DB's were
> closed/shutdown properly when the server rebooted - so we know that we
> aren't
> going to be missing rollback/commit operations.
> Thanks for any help you can offer - I might not be back till Sunday
> afternoon to check this thread - but only have till Tuesday AM to get the
> box
> back up and running.

Drive letters and MDF/LDF files...

All,
I'm writing to ask if anyone knows whether or not MS SQL server stores in any system tables the association between a database and the drive letter/directory path where its corresponding MDF/LDF files are located.
Thanks,
IsaacSELECT database_id
, name
, physical_name
FROM sys.master_files

SQL 2005 - not sure re 2000|||select filename
from master..sysaltfiles|||Exec master.dbo.sp_helpfile

Regards,

hmscott|||SELECT name
, physical_name
FROM [dbName].sys.database_files

Drive Failure

I had a drive failure last night. Sql Server was loaded on the drive that
failed (which also contained the OS). Fortunately, the log files were on
another drive and the databases on another and both of these drives are OK.
Does anyone know the correct procedure after reloading the OS and Sql Server
2000 on the new drive, for reattaching the databases to this new instance of
Sql Server.
Thanks for any help.
Brian
Try to attach the databases again,a dn then check the status of the
database. If its working you gotta be ok, if not you might try to check the
DBCC command to fixed the errors. dont know how long i will stay on the
wire this evening (yes, i am in europe ;-) ), but i thin if there is an
error all other guys here are able to help you.
If that all doenst work, i hope for you you gotta working backup
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
"Brian" <Brian@.discussions.microsoft.com> schrieb im Newsbeitrag
news:14C9F68D-E6D1-412D-81A9-8EDFFA42C4B6@.microsoft.com...
>I had a drive failure last night. Sql Server was loaded on the drive that
> failed (which also contained the OS). Fortunately, the log files were on
> another drive and the databases on another and both of these drives are
> OK.
> Does anyone know the correct procedure after reloading the OS and Sql
> Server
> 2000 on the new drive, for reattaching the databases to this new instance
> of
> Sql Server.
> Thanks for any help.
> --
> Brian
|||Hi,
Other methodology:- This work good for me once.
Easy way to recover the database after OS crash is,
1. After OS installation, Copy all .MDF and .LDF files to a new folder
(safe location)
2. Install SQL server and same Service packs (as old) in the identical
folder (Same as old installation)
3. Stop the SQL server
4. Copy the .MDF and .LDF files (took in step 1) to the same folders (Same
as old installation).
5. Start SQL server
Now login to query analyzer or enterprise manager and confirm all the
databases are online.
If any of the database is in suspect status, then check the cause for the
error in SQL server Error log. If it is critical you may
need to restore the database from Backup
Thanks
Hari
SQL Server MVP
"Brian" <Brian@.discussions.microsoft.com> wrote in message
news:14C9F68D-E6D1-412D-81A9-8EDFFA42C4B6@.microsoft.com...
>I had a drive failure last night. Sql Server was loaded on the drive that
> failed (which also contained the OS). Fortunately, the log files were on
> another drive and the databases on another and both of these drives are
> OK.
> Does anyone know the correct procedure after reloading the OS and Sql
> Server
> 2000 on the new drive, for reattaching the databases to this new instance
> of
> Sql Server.
> Thanks for any help.
> --
> Brian

Drive Failure

I had a drive failure last night. Sql Server was loaded on the drive that
failed (which also contained the OS). Fortunately, the log files were on
another drive and the databases on another and both of these drives are OK.
Does anyone know the correct procedure after reloading the OS and Sql Server
2000 on the new drive, for reattaching the databases to this new instance of
Sql Server.
Thanks for any help.
BrianTry to attach the databases again,a dn then check the status of the
database. If its working you gotta be ok, if not you might try to check the
DBCC command to fixed the errors. dont know how long i will stay on the
wire this evening (yes, i am in europe ;-) ), but i thin if there is an
error all other guys here are able to help you.
If that all doenst work, i hope for you you gotta working backup
HTH, Jens Suessmeyer.
http://www.sqlserver2005.de
--
"Brian" <Brian@.discussions.microsoft.com> schrieb im Newsbeitrag
news:14C9F68D-E6D1-412D-81A9-8EDFFA42C4B6@.microsoft.com...
>I had a drive failure last night. Sql Server was loaded on the drive that
> failed (which also contained the OS). Fortunately, the log files were on
> another drive and the databases on another and both of these drives are
> OK.
> Does anyone know the correct procedure after reloading the OS and Sql
> Server
> 2000 on the new drive, for reattaching the databases to this new instance
> of
> Sql Server.
> Thanks for any help.
> --
> Brian|||Hi,
Other methodology:- This work good for me once.
Easy way to recover the database after OS crash is,
1. After OS installation, Copy all .MDF and .LDF files to a new folder
(safe location)
2. Install SQL server and same Service packs (as old) in the identical
folder (Same as old installation)
3. Stop the SQL server
4. Copy the .MDF and .LDF files (took in step 1) to the same folders (Same
as old installation).
5. Start SQL server
Now login to query analyzer or enterprise manager and confirm all the
databases are online.
If any of the database is in suspect status, then check the cause for the
error in SQL server Error log. If it is critical you may
need to restore the database from Backup
Thanks
Hari
SQL Server MVP
"Brian" <Brian@.discussions.microsoft.com> wrote in message
news:14C9F68D-E6D1-412D-81A9-8EDFFA42C4B6@.microsoft.com...
>I had a drive failure last night. Sql Server was loaded on the drive that
> failed (which also contained the OS). Fortunately, the log files were on
> another drive and the databases on another and both of these drives are
> OK.
> Does anyone know the correct procedure after reloading the OS and Sql
> Server
> 2000 on the new drive, for reattaching the databases to this new instance
> of
> Sql Server.
> Thanks for any help.
> --
> Brian

Drive Failure

I had a drive failure last night. Sql Server was loaded on the drive that
failed (which also contained the OS). Fortunately, the log files were on
another drive and the databases on another and both of these drives are OK.
Does anyone know the correct procedure after reloading the OS and Sql Server
2000 on the new drive, for reattaching the databases to this new instance of
Sql Server.
Thanks for any help.
--
BrianTry to attach the databases again,a dn then check the status of the
database. If its working you gotta be ok, if not you might try to check the
DBCC command to fixed the errors. don´t know how long i will stay on the
wire this evening (yes, i am in europe ;-) ), but i thin if there is an
error all other guys here are able to help you.
If that all doens´t work, i hope for you you gotta working backup :)
HTH, Jens Suessmeyer.
--
http://www.sqlserver2005.de
--
"Brian" <Brian@.discussions.microsoft.com> schrieb im Newsbeitrag
news:14C9F68D-E6D1-412D-81A9-8EDFFA42C4B6@.microsoft.com...
>I had a drive failure last night. Sql Server was loaded on the drive that
> failed (which also contained the OS). Fortunately, the log files were on
> another drive and the databases on another and both of these drives are
> OK.
> Does anyone know the correct procedure after reloading the OS and Sql
> Server
> 2000 on the new drive, for reattaching the databases to this new instance
> of
> Sql Server.
> Thanks for any help.
> --
> Brian|||Hi,
Other methodology:- This work good for me once.
Easy way to recover the database after OS crash is,
1. After OS installation, Copy all .MDF and .LDF files to a new folder
(safe location)
2. Install SQL server and same Service packs (as old) in the identical
folder (Same as old installation)
3. Stop the SQL server
4. Copy the .MDF and .LDF files (took in step 1) to the same folders (Same
as old installation).
5. Start SQL server
Now login to query analyzer or enterprise manager and confirm all the
databases are online.
If any of the database is in suspect status, then check the cause for the
error in SQL server Error log. If it is critical you may
need to restore the database from Backup
Thanks
Hari
SQL Server MVP
"Brian" <Brian@.discussions.microsoft.com> wrote in message
news:14C9F68D-E6D1-412D-81A9-8EDFFA42C4B6@.microsoft.com...
>I had a drive failure last night. Sql Server was loaded on the drive that
> failed (which also contained the OS). Fortunately, the log files were on
> another drive and the databases on another and both of these drives are
> OK.
> Does anyone know the correct procedure after reloading the OS and Sql
> Server
> 2000 on the new drive, for reattaching the databases to this new instance
> of
> Sql Server.
> Thanks for any help.
> --
> Brian