April 11, 2011 at 3:55 pm
You’ve either volunteered or had the position thrust upon you, but here you are. You’re the DBA. You are being looked to as the person who will protect the companies’ data and you really don’t have a clue where to start. Let me suggest that one of the first things you should do is put together a good plan for backing up your database. This session will focus on the best practices, standards and methods that you can employ to ensure that you have a solid backup process for the databases under your charge. You’ll also learn how to restore these databases, because your backups are only good if you can restore them. At the end of the session, you should be able to go back to your office with confidence that you can begin to protect the data for your organization.
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
- Theodore Roosevelt
Author of:
SQL Server Execution Plans
SQL Server Query Performance Tuning
April 11, 2011 at 6:27 pm
Having been in the position you describe, wish I had heard your talk before my hair turned grey. Nice clear description of the position many are thrust into, with a clear description of what I will learn from your presentation, how I and my company would benefit. If I could have attended your presentation I certainly would have done so. In fact even now I most likely would learn something, that I should know and may be overlooking.
April 11, 2011 at 7:39 pm
Grant,
Nice description; down to earth and understandable.
I would guess (perhaps wrongly) that almost all people in the room have probably backed up a database. A full backup at least. Perhaps never tried to restore before. Perhaps mentioning terms like "point in time" restore and what is needed for that to work (log chain).
Issues that I have seen in the wild (leading to companies calling me) include:
1) Restore over top of the production database rather than making a 'copy' to sit on the same server. I know, restoring to another server is best, but I get calls after folks think this is going to be easy and blow away production.
2) Backup files ending up on the same physical drives as the .mdf/.ndf or .ldf's (backup to same logical drive letter, to different logical drive which is a partition of the same physical disk, to a shared SAN, or on VM drive which maps to the same physical disks).
This may not be in scope for your talk perhaps, and all of this detail should not end up in the description. However, maybe the description can hint at "no, your backups may not really be ok" with a buzzword or two to catch the attention of people who know super basic backups, but that's it.
Jim
Jim Murphy
http://www.sqlwatchmen.com
@SQLMurph
Viewing 3 posts - 1 through 2 (of 2 total)
You must be logged in to reply to this topic. Login to reply