Problem: I set up an SQL Server 2008 R2 test environment on a virtual machine using the free VMWare Server 2.0. My guest OS was Windows Server 2008 R2. I also installed VMWare Tools on the guest OS.

I could start SQL Server Management Studio (SSMS) without problems. However, as soon as I attempted to connect to the SQL Server, the whole VM stopped responding.

I couldn’t kill the VM without restarting the physical host. I had set up multiple VMs smoothly in the past but I still wondered, was the problem ME? Did I miss to do something during installation?

Solution: Okay, I didn’t want to have to admit this–but I did try to re-install everything. I thought maybe I did a “next-next” and missed to specify some options (that is, clicked through the installation wizard without reading. Nopes, that’s not in the dictionary but like OMG, it may be soon). Good news was, it wasn’t me since I still couldn’t connect to SSMS. I checked the Guest OS’s event viewer. Nothing there.

What finally clued me in was this: Troubleshooting SVGA drivers installed with VMware Tools on Windows 7 and Windows 2008 R2 running on ESX 4.0. It took awhile for me to find this because if you read the KB, you’d notice that it’s not really describing the problem that I was having (it says there “black screen” and “slow mouse performance”). The products affected don’t even include VMWare Server. And lastly, from my perspective, SSMS was the problem–not Windows Server 2008 R2.

Regardless, the problem was the SVGA driver that came with VMWare Tools (weeweeweee!). So I ran the VMWare Tools installer again and removed the SVGA driver.

And finally, the problem was fixed.

If you are encountering the same issue, I’m hoping you find yourself squealing weeweewee sooner than I did.

Is this causing you sleepless nights too?

This is only somewhat related to the main topic of this post…but doesn’t this installer design bother you too?

I see this in a lot of installers. When you check the feature for installation, it changes to this:

Shouldn’t the space requirement be shown BEFORE I even check the feature? #JustSaying

This is my contribution to Tom LaRock’s (blog | twitter) Meme Monday (Write a SQL blog post that tells a story in 11 words or  less).

I was tagged by one of my favorite girls, Erin Stellato (blog | twitter). So I’m tagging my favorites as well: Donabel Santos (blog | twitter), David Taylor (blog | twitter), and Karla Landrum (blog | twitter).

Yes, baby! I’m back.

So to make Thanksgiving this year better than the last (and the ones before that), I downloaded all the SQL Server 2008 Microsoft Certified Master (MCM) Readiness Videos that have been posted so far. My (not-so-evil) plan is to grab my iPod or my Droid when things become too err…enjoyable. So while they’re talking about babymaking and all the “challenges” involved in it (and how it can actually be really just sooo easy–”as long as Janice, you don’t stress too much.”)–I’ll just DROID them out and listen to Paul Randal tell me that I’m “spatial”! Ha!

1) Which format do I download?
If you’ve visited the site, you’ll notice that there are different formats available. I wanted to watch the videos using my phone (a Droid 2) or my iPod nano (4th gen, I think) so the links that I was interested in were the following:

Only two of the files I downloaded via the iPod link worked. So I tried downloading the MP4. Most of the MP4 files however would only play on my PC and not on my iPod or Droid. You may experience the same thing so here are some tips…

Tip 1: Use HandBrake to convert the MP4 (or the other video formats) to an MP4 format that your iPod can actually play. You can download the tool here for free: http://handbrake.fr/downloads.php. With the iTunes application (I’m using version 10), you can do the same thing but it takes sooo long and you can only do one at a time! Thanksgiving would be over before you finish. If you use HandBrake, the process is not only faster, you can also put all the files that you want to convert on a queue  and you can just leave it until it’s done.

Tip 2: Now–this really depends on what your in-law tolerance is. The longer you can stand them, the less videos you have to download. I for one have a very high in-law tolerance. So–to download all–use the free Download Manager from SourceForge. Here’s the link. Just copy the target link of each video and add it to the queue. Leave it running overnight and you’re all done the next day.

Tip 3: When you’re done downloading and converting the videos, just add them to your iTunes library and voila—THANKSGIVING.

To play the files on your Droid, just copy the converted MP4 files to your SD card and VOILA–yep-yep–it’s Thanksgiving again! Ahh..what do they call these things again? Oh yeah…the gifts that just keep giving.

Happy Thanksgiving everyone!

P.S. To my in-laws–come on, I’m just kidding. Stop being so cranky. That stresses me out–and we don’t want that, remember?

1) There were just enough tracks and sessions to choose from.
2) There was ample time to go from one session to another.
3) The sponsors were situated near the classrooms so it was impossible to miss them. (In SQL Saturday – Charlotte, the sponsors were in another building.)
4) Parking was easy…(it was hard for me to find where I parked my car though–but then that happens all the time).
5) The giveaways were nice. The sticky ball is the bomb! Apparently, it’s not a good idea to throw it to a flat-screen TV. Why? First, because it wouldn’t stick (I tried so many times). And second, I was told that if I didn’t stop trying, I would lose all my privileges. What’s with men and their televisions???
6) It was well-attended, the speakers were awesome,  the food wasn’t bad, and…
7) They hid the donuts! Seriously, LUCKY ME. That would have been another 5 lbs I’d have to lose this week.

Why you should attend SQL Saturdays
This is what the post is all about really. I want to encourage you to never skip an SQL Saturday in your area. Let me tell you why.

1) It’s the best time to get starstruck
Maybe you don’t get a kick out of it. But I do–and I’m not ashamed to say it. I get starstruck when I see SQL Server MVPs, authors, and tweeps. I think I’m innately a fan.  It’s just the way I’m built. SQL Saturdays is like the Oscars–only, it has smarter people. And it’s more fun. Orlando Bloom will never know my name (and I doubt he’ll ever win an Oscar)–but SQL Server authors and MVPs–if you stalk them long enough, they will. And they will really say hi!

Anyway, if you’re like me, some stalking tips:

a) Always have a pen when you’re having a book signed.
Or just die from embarrassment your whole life. I had DBA Survivor signed and Thomas LaRock (blog | twitter) had to find a pen that worked to sign it. When I close my eyes, I still remember him saying, “you’re new to this stalking thing, huh?”. So bring a pen. Sponsors give it away–use it!

b) “I follow you!” is not the best way to introduce yourself.
And to follow it with “You’re lotsahelp, right? But I don’t know your name!” is not a good idea either.

Eric Humphrey (blog | twitter)  must have thought I was crazy. And no, of course I didn’t stop talking. I made it worse and said–”You look exactly like you do on Twitter!”. I said it like it was the world’s most amazing discovery. They say kids say the darndest things and man, I wish I had that excuse. He was nice about it though and replied that looking exactly like you do on Twitter is how it’s supposed to be. (If that is the case, I’d probably faint if I see @sqlchicken).

c) “You’re sqlcraftsman!” is also not a good way to start a conversation.
I said this and the guy said, “no, I’m Jim.”. OMG–talk about embarrassing.

So anyway, always start with a hello. In a normal world, that usually works best.

2) Learn, learn, learn
The learning benefit is a given. SQL Server is soo big. There’s so much to learn. SQL Saturdays allow you to learn about topics you’ve never heard of (xquery???), learn about topics you’ve kinda heard of (is powershell =  powerpuff?), and learn more about topics you already know (t-s-q-l). You get all these for free. You can ask questions just by raising your hand. And trust me, that’s a big deal. I always try that with my mother-in-law and it never works.

But you must be thinking–you can easily learn  from PASS’s virtual sessions. You can even learn just by downloading the sessions. Or you can just read a book. So why attend, right? Why make time?

One word: CHANCES.

3) Chances
Think of an SQL Saturday as match.com or eharmony.com. It’s a place where you meet people who do and like the same things that you do. And you don’t have to take a personality exam to get in. You just–go. For every session, you get the chance to find someone to like, to talk to, and to have fun with. You just have to grab the chance.

It’s so easy to pretend that the world consists of just your family, your team, and your current set of friends. But the world is bigger than that. And you can be so much more.

I had several surgeries last year. One was so bad I remember asking one doctor, “Will I die?”. And all he said was–”you’re at the right place at the right time.”  (Yeah, he did his best to be reassuring ).  When I woke up from the surgery (yay! I survived!), I felt lucky, yet, I also felt irrelevant. I started asking, how many people have I helped? How many people have I made an impact on?

How many have I reached out to?

Not too many. I’ve always been too busy.

So what does this have to do with going to SQL Saturdays? If you’re reading my blog, then most likely you are an SQL Server professional like me. I know it’s easy to keep to yourself. But events like SQL Saturdays give you a chance to be relevant. They give you a chance  to reach out to people you can easily have a huge impact on. Afterall, you’re already into similar things!

All it takes is one hello.

“Hello, I’m Janice Lee.”

Every session I attended, I said these words to the person beside me. I left the event with three new friends: Derek who went to Belgium early this morning for a vacation with his wife, Vishal who looked 13 but was really 29 years old and was an SQL Server whiz kid, and Elizabeth who quit her job because she knew what was important to her. I have their email addresses, I encouraged them to join twitter, and I think I convinced Derek to ditch his planner and get himself a smartphone when he comes back from Belgium.

You must be thinking–so what? Well, this is the chance I was talking about. In one day, I just expanded my world and added three people to it. I told them about #sqlhelp and I encouraged them to blog and to be active in the community. I talked, I reached out, and I gave myself the chance to be relevant. You can’t do this in a virtual session. You can’t do this when you just read a book. You can’t do this when you don’t go out there.

I know it takes two to tango. Some people just don’t like to interact so just leave them alone (unless you’re like me who just pretend to not get the message ). Don’t let it stop you from taking the chance though and from saying hello. Because that one hello can make a difference.

Conclusion
Don’t wake up one day realizing that there’s a world out there–as if that fact wasn’t staring at you every time you opened your eyes. When you get the chance to attend events like this–grab it. And as I said–going to one to learn is a given. But definitely don’t ignore the additional benefits. Make time to attend it, smile, and say hello. This way, you’ll get and learn more than SQL Server. There’s more to life afterall than databases

P.S. Shout out to Allen White (blog | twitter) , Kevin Boles (twitter), Tim Chapman (blog | twitter), Grant Fritchey (blog | twitter), Andy Leonard (blog | twitter), and Eli Weinstock-Herman (blog | twitter) who all said hi. And to the guy who sat beside me and gave me the book he won–THANKS! Shawn, right?

And for the wonderful note on my book and all the kind words, thanks to Thomas LaRock (blog | twitter). I was a lost puppy early this year (what an understatement). I listened to your podcast and I found my way home. I’m hoping I can pay it forward.

For more information on SQL Saturday, go to www.sqlsaturday.com.

This text is from my high school yearbook. I think the guy who wrote this to describe me wanted to kiss my bacon. When he said four-digit IQ, he probably meant .0001. But seriously, back then, I really did want to make the world a better place. That this slowly became a cliche as I grew older is really sad and disappointing.

I’m not writing about the PASS election process. I’m too new in PASS to even have a strong opinion about it. I’m also not writing about Steve Jones. The only direct relationship I have with Steve Jones are his Voice of the DBA podcasts. However, I’ve been reading some articles about him in the past weeks…and, looks like Steve Jones is more than a podcast to a lot of people. These people are not happy about his  exclusion from the Board of Directors election and what’s awesome is, these people are speaking up about it. Passionately.   

In the short time that I’ve been with the SQL community, I’ve seen passion so hot it burns. It reminds me of the days when I actually thought I could change the world.

I’m different now from the girl described above. I’m no longer desperate to make the world a better place. In the workplace, I’ve mastered the art of avoiding confrontations. It’s just more…peaceful. But being part of a community where people stick their necks out for people and ideals despite the possibility of conflict is kinda inspiring. It makes me think it may be possible for me to change the world afterall. Peace can be overrated anyway; I think I can forego it once in awhile for the possibility of something as underrated as change.

Of Wasabis

Wasabi chips. I bought this last weekend. As soon as I took my first bite…I stuck my tongue out and said–”Ugh! It tastes like wasabi!”

The package was labeled wasabi. It had a picture of a wasabi. Not sure really why I was so surprised. I guess it tasted too much like wasabi. Yeah, yeah…I know what you’re thinking…how else was it supposed to taste like??? I know it doesn’t make sense but the taste really DID overwhelm me. Just saying…

Of Bikinis

Three years ago, I copied a bunch of pictures to an external drive. I actually checked quickly if the transfer was a success after…keyword being quickly. I just looked at the thumbnails and all looked well so I deleted the original images from my laptop. When I opened the pictures last Saturday, half of the pictures looked like this:

I lost a set of pictures with my college friends, a set of pictures with my dogs, and ONE bikini picture (yes, I could actually fit in one a long, long, long time ago).

Of Database Backups

I think some people forget that backups are just operating system files–like my pictures are files, like PSTs are files, and like documents are files. And files behave like files–the same way wasabi chips taste like wasabi. When you move files or copy them or email them or write to them–anything can happen. Files can get corrupted. So when you find your unverified backup files to be corrupted or invalid, it’s not really a question of why it happened–but why is it that you didn’t verify them knowing that they’re basically “just files”? This probably sounds so dumbed down but this is as non-technical as I can make it to be: backup files are files. How redundant, eh?

Instilling Paranoia
Be paranoid. Do verify your backups.  Get started now. Because when you’re the one in charge of the database, whether by accident or not,  you just can’t forget that there’s more than a bikini picture at stake.

Now, really, all this talk about bikinis is making me want to skip these donuts. Next topic please.

More Information
Verifying Backups

Hooooo-kay! Moving on…

With a transaction log backup, you gain the ability to restore your database to a point-in-time contained in the backup. For example, if a table is accidentally emptied via a DELETE operation that’s not within an explicit transaction, you can:

1) If possible, stop all database activities as soon as you learn about the accident then take a transaction log backup.

2) Restore the most recent full database backup and most recent differential backup (if any) to a new database (WITH NORECOVERY).

3) Apply your transaction logs up to the point prior to the delete.

4) When you have your deleted records back (in the new database), re-insert them to the table in the original database. Once you have inserted the data back, you would have to do some work to ensure that your database is how it really should be (i.e. if the DELETE that you’re trying to undo didn’t happen, what would the database state be?).

The tricky part really is figuring out up to what TIME to restore.

1) If you know the exact time, just apply each transaction log backup and specify STOPAT=TIME, WITH RECOVERY. As long as the time you specified is not met, the database will remain unrecovered. For example,

RESTORE LOG NewDB FROM DISK='C:BackupAdventureWorks.trn' WITH RECOVERY,
STOPAT = 'Aug 12, 2009 10:00:00 AM'
GO

2) If you know just the time range (for example, from 3:15PM-3:30PM), it’s a bit more tricky. You need to restore your log backups to different times (3:15PM, 3:16PM, 3:17PM, and so on) using STOPAT and you need to be able to look at the data each time before restoring more backups, and before changing the STOPAT time. SQL Server allows you to do this using an option called STANDBY. It allows you to recover your database, read it (you cannot modify), and restore more log backups. Check Tibor Karaszi’s Minimizing Data Loss for more information on how to do this.

The less you know about the time the accident happened, the more tedious the recovery gets. Imagine doing this if all you know is that the delete occurred yesterday and no time is specified…12 midnight…1am…2am…it’s not a good situation to be in.

Is there an alternative?
Yes. You can restore to a log sequence number instead–or to a point before it. You can look at restoring to an LSN as an alternative or a complement to the point-in-TIME restore. There’s some guesswork involved though. What you need are:

1) The name of the table
2) The number of records deleted (or at least, an estimate)
3) The time of the disaster/accident. You will see later that this is still a nice-to-have.

To illustrate, let’s delete all records in the AdventureWorks’s Production.TransactionHistory table. I’m using SQL Server 2005.

--delete all records
delete from Production.TransactionHistory

This deletes 113443 records.

Finding the LSN of the Point of Disaster
fn_dblog is a system UDF that’s undocumented by Microsoft. Information about it can be found online (yeah, it’s very well documented for something that’s supposedly undocumented). fn_dblog exposes to you some information about the database’s transaction log.

The plan is to use fn_dblog first to find the LSN of the point of disaster, and, if we don’t find it, to use fn_dump_dblog instead. fn_dump_dblog shows similar information as fn_dblog and more. fn_dump_dblog can read transaction log backups.

If the transaction that we’re looking for is not in the database’s transaction log, most likely it’s been overwritten and is already in a transaction log backup.

Reminder: Use fn_dblog, fn_dbdump_dblog, and other undocumented functions with caution, especially in production DBs. Actually, when I ran the scripts I used in this post on my development DB, they were extremely slow.

Also note that future versions or service packs may change how these functions behave. Make sure to test the scripts where you use them every time you make a change to your SQL Server installation.

1) Find the transaction’s Transaction ID. All the delete operations within the transaction will belong to one Transaction ID. We can find this using fn_dblog and the estimated/actual number of deletions.

USE AdventureWorks
GO
SELECT [Transaction ID], count(*)
FROM fn_dblog(DEFAULT, DEFAULT)
where AllocUnitName LIKE '%Production.TransactionHistory%'--table name
GROUP BY [Transaction ID]
HAVING COUNT(*) >= 113443 --(estimated/actual) number of deleted records

The result is this:

Transaction ID REC_COUNT
0000:0000130c 340329

(1 row(s) affected)

Deletions that are done on heaps will have a count that’s closer to the actual number of records deleted. The presence of indexes will result to a higher count but just keep in mind that the number of records deleted will be the minimum count.

If above query results to more than one Transaction ID, knowing the time (or even just a time range) that the delete happened really helps. We will discuss this later.

2) Next, get all the operations that have the Transaction ID we found in the previous step to verify if it is the transaction we are looking for.

SELECT
[Current LSN],
Operation,
Context,
[Transaction ID],
[AllocUnitId],
[AllocUnitName],
[UID],
[SPID],
[Begin Time],
[Transaction Name]
FROM fn_dblog(DEFAULT, DEFAULT)
WHERE [Transaction ID] = '0000:0000130c'
ORDER BY [Current LSN]

The results are as shown below:

Verifying the Results
The delete we performed will show as Operations = LOP_DELETE_ROWS in the transaction log. That’s what we see in (1). The table we deleted from has the following indexes:

and this coincides with (2).

The date in (3) is what we would have to use if we have several Transaction ID candidates and we’re not exactly sure which transaction to select. If we have the time of the accident (or at least, an estimate) we can select the transaction that has a [BEGIN TIME] closest to the time we have. This is the reason I said earlier that the date is nice to have.

So, based on the results, it looks like we have the correct Transaction ID.

4) Look for the LSN of the point of disaster.

This would be the first LSN of the transaction and the value of Operation should be LOP_BEGIN_XACT. In this example, it’s 00000026:00000458:0002. BINGO! This is our point of disaster. We want to restore not to this LSN but right before it.

Performing the Restore
Restore the most recent database backup and differential backup (if present) and apply the transaction log backups specifying the LSN where the restore should stop (right before).

--execute this after restoring the full database backup, the differential backup (if any), and the subsequent transaction log backups
RESTORE LOG [NewDB] FROM  DISK = N'C:BackupAdventureWorks.trn' --NewDB is the new database we're restoring to
   WITH STOPBEFOREMARK= 'lsn:00000026:00000458:0002' --this is the LSN of the beginning of the transaction which is our point of disaster
GO
RESTORE DATABASE NewDB
   WITH RECOVERY;

Once the restore is completed, extract the deleted data from the new db and re-insert them to the original table.

What if we can’t find the delete transaction using fn_dblog?
Turn on trace flag 2537 and try again. If you still can’t find it, a transaction log backup may have been performed already and the delete transaction in the log may have already been overwritten. If this is the case, then we need to do the same steps we did above but this time, we want to use the fn_dump_dblog command. I discovered fn_dump_dblog via…what else…GOOGLE! Yeah, finding it made me GIDDY and no, fn_dump_dblog “ain’t” shoes.

As I said earlier, it shows pretty much the same info as fn_dblog BUT it has the added ability to read transaction log backups. Because we no longer have the transactions in the database’s transaction log, we will attempt to read the transaction log backup file that was created right after the accident happened using fn_dump_dblog.

SELECT [Transaction ID], count(*)
FROM fn_dump_dblog(DEFAULT, DEFAULT,DEFAULT, DEFAULT, 'C:BackupAdventureWorks.trn', DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
GROUP BY [Transaction ID]
HAVING COUNT(*) >= 113443 --(estimated/actual) number of deleted records

In this test case, we only get one Transaction ID that meets the conditions we specified (it’s the same Transaction ID that we got earlier using fn_dblog). If there are more, we need to look at the operations of each Transaction ID and make an (educated) guess as to what Transaction ID corresponds to the accidental delete. The problem with fn_dump_dblog is for some undocumented reason, the AllocUnitName is empty. This makes it difficult to know what object/entity the DELETE operation was performed on. Regardless, there are still ways we can extract the information we need.

To check the operations of the Transaction ID that results from above code, we run the following:

SELECT
[Current LSN],
Operation,
Context,
[Transaction ID],
[AllocUnitId],
[AllocUnitName],
[UID],
[SPID],
[Begin Time],
[Transaction Name]
FROM fn_dump_dblog(DEFAULT, DEFAULT,DEFAULT, DEFAULT, 'C:BackupAdventureWorks.trn', DEFAULT,DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT, DEFAULT)
WHERE [Transaction ID] = '0000:0000130c' --change this to WHERE [Transaction ID] IN ('0000:0000130c', ...) if there's more than 1 Transaction ID candidate
ORDER BY [Current LSN]

Here’s the result:

I have highlighted the fields you can look at to verify the LSN of the point of disaster. Pick the transaction that has a BEGIN TIME that’s closest to the time of accident. The time information here becomes more important since we don’t have the AllocUnitName. For this reason, I would recommend that you try to find the LSN while the transaction is still in the database’s log.

Tips

a) If you’re in full recovery model and have done a full database backup yet have never taken transaction log backups, you should be. If a minor accident like the example discussed in this post happens to you, you can still use above steps. I recommend executing the fn_dblog command first to get the LSN of the point of disaster and then perform a transaction log backup (you would need it to do a point-in-time restore.) And of course, going forward, continue doing transaction log backups.

b) Third-party transaction log reading tools can help you eliminate all the guesswork so also consider these options when trying to find the LSN of the point of disaster.

c) Going forward, secure your database to make sure users are not allowed to make these disastrous changes to the production database. Also consider using transaction log shipping and configure it such that the logs are restored to your destination only after some delay. This gives you quick access to an older state of your database should a disaster like the one discussed in this post happens. I’ll be discussing this more in detail in a future post. Tibor Karaszi’s Minimizing Data Loss also has some tips on avoiding this disaster in the future.

More Information
Recovering to a Log Sequence Number

“Get where?”, you ask. There. That place where dreams are.

It gets frustrating sometimes to hear ourselves saying…

I don’t know that.
I haven’t tried it.
I have no idea what you’re talking about.
I have never heard of it.
That sounds familiar but I’m not sure.
I’ve never really set one up.
I kinda know the concept but…I’d have to review how to do that.

Wouldn’t it be just nice to say…I know.

Reading inspirational stories give you that feeling of “Yes, I can do it too.” But then you go back to your daily grind, you look at your goals, and you realize, man, you still have a long way to go. And it’s frustrating.

I remember a conversation I had once with some family friends. I asked, “How do I make sure I don’t get caught for speeding?” One advised never to drive more than 5 mph over. Another said slow down if I see a suspiciously-cop-looking car. My brother-in-law said just always make sure the driver of the car in front of me is driving just as fast or faster.

Then finally, my 10-year old niece said, “Aunt Janice, if you drive the speed limit, I don’t think you’ll get caught.” And we all laughed.

But it’s not funny, isn’t it? Because truth is, there shouldn’t be a way “around” things. Getting “there” takes time. And just like driving, sometimes we all wish we had left earlier.

We all have moments like this…of self-doubt, of impatience, of thinking, “man, I wish I started this a long time ago!”.

When I told my bestfriend this, she said that my problem’s I keep focusing on how far I still have to go to get to my destination. She said that sometimes, I need to look back instead and see how far I’ve come. She said pause and give yourself some credit.

This is not an inspirational story for I don’t seek to inspire. If you’re reading this though and you get it, I just wanted you to know, you’re not alone.

I’ve been blessed to have people around me who have never made me feel that my questions were stupid. They have told me I’m dense though…so go figure. Anyway–I know it doesn’t seem like I just wrote a disclaimer..but I did.

Last week, I was performing tests on transaction log backups. Everytime I restored a database backup of a database that was using a full recovery model to a new database, I would immediately do a full database backup to start the backup chain. (I needed to create transaction log backups for testing.) After doing this process 5 times, I thought–is this really necessary? That is, if I create a full database backup of a database that’s using the full recovery model, then restore it to a different db, do I really still need to make a full database backup *just* to start the backup chain? Can I just perform a transaction log backup without doing a full database backup? Afterall, I already have a full db backup. Will the database be in autotruncate mode right after the restore?

Note: Not familiar with recovery models? Read Recovery Model Overview and When is FULL Recovery not Really FULL Recovery.

What I kinda know
When a database is using the simple recovery model, it is in autotruncate mode. When you switch the recovery model from SIMPLE to FULL or BULK_LOGGED, it is important to perform a full database backup first to complete the change.  If you don’t, then the database will remain in autotruncate mode. Autotruncate simply means SQL Server is automatically truncating the database’s log when it gets almost full.

To check if a database is in autotruncate mode, I use below code:

--last_log_backup_ls is NULL if in autotruncate mode
select B.name, A.last_log_backup_lsn
from sys.database_recovery_status A inner join sys.databases B
on (A.database_id = B.database_id)

So to answer my questions…
I did some tests. First, I created a test database (TestDB), changed its recovery model to FULL, and performed a full database backup.

USE master
go
--Create the test database
CREATE DATABASE TestDB;
GO
--Set the recovery model to full
ALTER DATABASE TestDB SET RECOVERY FULL;
GO
--Full database backup
BACKUP DATABASE TestDB TO DISK = 'c:BackupTestDB_Full.bak';
GO

Right after I did  a full database backup, I checked and as expected, the database was no longer in autotruncate mode. (The last_log_backup_lsn was not null).

Next, I restored the full database backup to a different database (TestDB2).

RESTORE DATABASE [TestDB2] FROM  DISK = N'c:BackupTestDB_Full.bak' WITH RECOVERY,
      MOVE 'TestDB' TO
'C:TestDB2.mdf',
      MOVE 'TestDB_log'
TO 'C:TestDB2_log.ldf'
GO

Right after the restore completed, I checked if the TestDB2 database was in autotruncate mode:

--last_log_backup_ls is NULL if in autotruncate mode
select A.last_log_backup_lsn from sys.database_recovery_status A inner join sys.databases B on (A.database_id = B.database_id)
where B.name = 'TestDB2'

It wasn’t. The result was not NULL even if I haven’t performed any backup…

I checked if I could do a transaction log backup without doing a full database backup.

--Perform a transaction log backup
BACKUP LOG TestDB2 TO  DISK = N'C:BackupTestDB2.trn';
GO

Success! SQL Server allowed me to!

So, in summary,

1) Will the database be in autotruncate mode right after restore? No.
2) If we create a full database backup of a database in full recovery model, then restore that to a different db, can we just perform a transaction log backup without doing a full database backup? Yes.

Why?
I think it’s because backup chains are primarily dependent on continuous LSNs. According to this article, two backups are consecutive if the LastLSN of the first one is greater than  or equal to the FirstLSN of the next one. In our test…

RESTORE HEADERONLY
   FROM DISK = N'C:BackupTestDB_Full.bak'

FirstLSN: 49000000006100037
LastLSN:  49000000007900001

RESTORE HEADERONLY
   FROM DISK = N'C:BackupTestDB2.trn'

FirstLSN: 49000000007900001
LastLSN: 49000000009300001

they’re equal. And yup, I tried restoring and it worked. I repeated the test. This time though, right after I restored to a new database, I performed a full database backup before doing a transaction log backup.

USE master
go
--Create the test database
CREATE DATABASE AnotherTestDB;
GO

--Set the recovery model to full
ALTER DATABASE AnotherTestDB SET RECOVERY FULL;
GO

--Full database backup
BACKUP DATABASE AnotherTestDB TO DISK = 'c:BackupAnotherTestDB_Full.bak';
GO

RESTORE DATABASE [AnotherTestDB2] FROM  DISK = N'c:BackupAnotherTestDB_Full.bak' WITH RECOVERY,
      MOVE 'AnotherTestDB' TO
'C:AnotherTestDB2.mdf',
      MOVE 'AnotherTestDB_log'
TO 'C:AnotherTestDB2_log.ldf'
GO

--Do a Full database backup of the newly restored database
BACKUP DATABASE AnotherTestDB2 TO DISK = 'c:BackupAnotherTestDB2_Full.bak';
GO

--Perform a transaction log backup
BACKUP LOG AnotherTestDB2 TO  DISK = N'C:BackupAnotherTestDB2.trn';
GO

The generated LSNs actually meet our criterion for consecutive backups; see below:

--full database backup of original db
RESTORE HEADERONLY
   FROM DISK = N'C:BackupAnotherTestDB_Full.bak'
go

FirstLSN: 49000000006100037
LastLSN: 49000000007900001

--full database backup of restored db
RESTORE HEADERONLY
   FROM DISK = N'C:BackupAnotherTestDB2_Full.bak'
go

FirstLSN: 49000000009600043
LastLSN: 49000000011400001

--tlog backup of restored db
RESTORE HEADERONLY
   FROM DISK = N'C:BackupAnotherTestDB2.trn'

FirstLSN: 49000000007900001
LastLSN: 49000000012000001

And yup, I was able to restore the transaction log backup using each of the full db backups as base.

Imagine That!
If this happens in real-life, say you lose the full db backup that starts a backup chain (maybe someone deleted it or it was moved to a different planet), there may actually be a slim chance that you have another copy lurking somewhere. Keyword I think though is slim. Thoughts?

And, no, I still think there are no stupid questions.

Oh that First Kiss
Yes, that darned first kiss. His name was Ricky, the jerkmy first love. I knew it was eventually going to happen. I daydreamed about it, thought a lot about how to do it, asked my friends about it, and pretty much geeked (researched) my way to it. With all the thinking and feeling I did prior to “the event”, the whole kissing thing already seemed and felt so real. But experiences like this cannot be “just” imagined…it’s atomic…all or nothing. It either happens or it doesnt.

When he asked me to close my eyes, I thought, OMG, am I really going to do this? And the moment I did, I had that momentous FIRST kiss with that jerk my first love.

Everything else faded. Even the voice inside my head (not mine but my mom’s) stopped talking. It was actually happening. Just the two of us. We both reveled in the isolation.

And then it was over. That kiss changed me. I was in a consistent heaven state for a long time. It didn’t matter where I really was…in school, at home–I was in heaven.

Years have passed. Boyfriends have come and gone. There’ve been second, third, fourth and more kisses. But still, nothing beats that first kiss. There’s something about FIRSTs that just stays with us no matter what. Some durability that’s unique to all our FIRSTs.

Okay, enough. I’m stopping.
Yeah, that was kinda a pain to read huh? Come on, humor me. Aren’t you tired too of all those debit-credit bank examples to illustrate transactions??

So, how is this dorky kissing event even remotely related to what a transaction is?

Transactions are atomic.
It’s all or nothing. It either commits or aborts. Just like that kiss. It doesn’t matter if I practiced with a pillow a thousand times (yeah, looking back, that was disgusting). Until the kiss actually happened, it really actually didn’t happen. The kissing plans could be rolled back; the actual kiss? No way.

Transactions are isolated.
There could be a million other events going on while that kiss was happening. There could have been a guy wishing he was in Ricky’s place (oh-ho!) but nothing else could mess with that transaction…nobody else could take away that first. That transaction owned me!

Transactions are consistent.
That kiss left me in heaven–and if that’s not a logical state to be in–I don’t know what is. A kiss that special wouldn’t have allowed me to be in an illogical state. Happy, yes. Illogical, no.

Transactions are durable.
Even an earthquake couldn’t have stopped that kiss the moment it happened. In the past years, I’ve experienced a lot…but hey, the first kiss will always be the first kiss. I can’t destroy it nor recreate it. I can’t pretend that it didn’t happen because (thank God) it really did.

Conclusion
No conclusion. I’m already feeling so bad I wrote this. It’s (r)ICKY and cheesy…but, hey, it’s non-technical! And maybe, just maybe, I made it all up…:D

Ricky, please dont get ahead of yourself. I was really just forcing an analogy. And no, it wasn’t THAT good.