SQL Server 2005 added the STOPAT option for the RESTORE DATABASE command. This sounds great - we can stop at some point in time during the database backup process was running! Or? No, we can't. Here follows some tech stuff why not, and then what the option is really meant for: A database backup includes all used extents and also all log ...

''Never'' is a strong word, so let me say that we really really want to avoid it, if at all humanly possible. In short, we will have a (potentially) broken database, both at the physical level and at the logical level. Read on. Just to be clear, when I refer to a ''log file'' here, I'm talking about a transaction log file, an .ldf file. Ever so ...

This is really basic, but so often overlooked and misunderstood. Basically, we have a database, and something goes south. Can we restore all the way up to that point? I.e., even if the last backup (db or log) is earlier than the disaster? Yes, of course we can (unless for more extreme cases, read on), but many don't realize/do that, for some ...

Seems like a simple enough question, right? This question (but more targeted, read on) was raised in an MCT forum. While the discussion was on-going and and I tried to come up with answers, I realized that this question are really several questions. First, what is a rollback? I can see three different types of rollbacks (there might be more, of ...

Are you stupid, you might think... But stop and think for a while. Model is no different from other databases. And by default it is in full recovery model. So as soon as you do your first database backup (you do backup your system databases, right?) the log for model will start filling up and autogrow. ''But, hey, I don't do any modifications in ...

The story usually goes something like: Q - How can I restore only this table?A - Put it on its own filegroup and you can do filegroup level backup and restore. The problem with above answer is that it most likely misses the point. We need to ask ourselves:Why do you want to do a table level restore? The answer to the question is very ...