Sean, I understand where you're coming from.
We're in a similar boat here, as I would expect are many others. Not withstanding today's economy.
Despite repeated complaints to management, (including senior business management), our situation is this; The self-appointed "DBA" (in a separate, `development team' on another floor) unfortunately knows less than a junior wielding two O'Reilly books and a KB print-dump. She's got the job, and is great at pouring honey into the ear of the person who also pours honey into the ear of the higest muckety-muck.
Surely, it would be ideal to be able to learn the DBA "trade", but again.. What we want and what we can have are often very different things. :)
I, personally have run into the following problems, which (to echo squillman's rather blunt, but not altogether incorrect) did require much of the googling.
- Tranlogs. You're right. What the heck were these things? So we had to restore a database and server, what does `replay the tran logs' mean, exactly? :)
- Wait, what do you mean these databases just get bigger? How do we shrink them? Or at least maintain their growth?
- Standardization of installations across different servers, (this image is for "dev", this image is for "prod" and this little image cried all the way home, from the market. :)
- Maintenance scripts and how to help manage the databases over a long period of time, (kind of like growing houseplants and making sure they don't turn into kudzu.)
- Always making sure, the proggies go on the C:\, the logging and/or databases go on the D:\, which kind of formulated our standardization, (C:\ is two mirrored disks, D:\ is usually a RAID5 affair.)
- Having to purchase a separate SQL licence and client for backups.
- Check out managing users that the development team assigns to the SQL database itself, managing DBO roles, etc. Ensure you've got a good security model when it comes to user rights within the database.
- Research of a domain service account that the SQL services can operate as. What rights that service account needs, if any at all.
(You've hit some pretty good ones, in your post.)
Since you're operating at a handicap like some others, make sure you spread the SQL knowledge amongst the team, if you can. Share what you know, teach others the same. Be friendly. It's a real pain having to wear the SQL hat, but at least many eyes and thought processes are better than one single one.
However above all, try like the devil to get a DBA on-staff. :)