Board index MS SQL Server

strictly for my own betterment...

strictly for my own betterment...

Post by oliver je » Sun, 21 Oct 2001 07:47:14



I have a question.  It's not a real scenario that I'm facing or a disaster
or anything like that, just an academic question.  I remember reading a
scenario like this one, but I can't remember the answer.

If I have two different data files in two different file groups, one for
data/clustered indexes and one for nonclustered indexes.  If the drive that
the non-clustered index file group becomes corrupt and irretrievable, and
there is no acceptable back-up (e.g. the backup from the night before is too
old), can the database still be recovered with only the filegroup with the
data/clustered indexes and the transaction log file?

thanks,
oliver.

 
 
 
Top

strictly for my own betterment...

Post by Dwayne Lancl » Wed, 24 Oct 2001 05:01:26


This scenario will not work.  Your transaction log will have references to
tables in the unrecovered file/filegroup and the database will not be
recovered.

------
Dwayne Lanclos
Microsoft SQL Server Support

Please reply only to the newsgroup so that others can benefit.
When posting, please state the version of SQL Server being used and the
error number/exact error message text received, if any.
This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.
? 2001 Microsoft Corporation. All rights reserved.

--------------------


> I have a question.  It's not a real scenario that I'm facing or a disaster
> or anything like that, just an academic question.  I remember reading a
> scenario like this one, but I can't remember the answer.

> If I have two different data files in two different file groups, one for
> data/clustered indexes and one for nonclustered indexes.  If the drive
that
> the non-clustered index file group becomes corrupt and irretrievable, and
> there is no acceptable back-up (e.g. the backup from the night before is
too
> old), can the database still be recovered with only the filegroup with the
> data/clustered indexes and the transaction log file?

> thanks,
> oliver.


 
 
 
Top

1. Julian day calculation is wrong (strictly speaking)

Hello!

I'm using the Julian Day Count for storage of dates in my
application, because I don't need sub-day resolution and
PostgreSQL makes my life much simpler because it can convert
to and from JD by itself.

However, I've found that the method which is used to generate
the Julian Day for a given date in the Gregorian Calendar is
somewhat wrong: It returns always the number of the JD that
starts at noon on a given date, disregarding the time of day.

Now, I'm not going to complain too loudly about this, because
it's just what I need -- I'm simplifying the calculations in
my app in just the same way. But it's still a nonstandard
behaviour which could be a problem to some people.

I don't know what would be the best way to fix this (or if it
needs to be fixed at all); I just wanted to remind you of this.
Feel free to disregard this message.

--
Christian Ullrich                   Registrierter Linux-User #125183

"Deliver."

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate

message can get through to the mailing list cleanly

2. Error 4318

3. Strictly Enforcing Query Plan Stability

4. Best books to become Oracle 8i DBA

5. red and white WINE STRICTLY KOSHER

6. Sp4 install problem

7. STRICTLY CONFIDENTIAL

8. Solaris Rebooting because of DB2?

9. Is oinstall group strictly necessary?

10. ******** OWN YOU OWN INTERNET BUSINESS *******

11. Accessing tables you don't own???

12. Install on workstation tries to dial own machine and dies

13. Roll your own security


All times are UTC
Board index