Comments posted to this topic are about the item DBA Team Mashup
Great article. A couple quick notes: Monitoring--I enjoy just sitting and watching system status data. The good thing about this is I immediately know when something is wrong. Troubleshooting--DBAs are natural problem solvers. Most of the time all you need to do is get out of their way. Operations--This is where the rubber meets the road. Get good at all aspects. Projects--IT work is project work. Everyone should be good at all project roles and should be able to move between them fluidly.
One Orange Chip
You're first sentence struck me.
Have you ever been the sole DBA at a company from the ground up? Me either.
Yes, almost always in my case.
Michael L John
If you assassinate a DBA, would you pull a trigger?
To properly post on a forum:
About 20 years ago I had the rare privilege to architect a system from scratch and lead the development team. I built in all of the things I had ever wanted and got rid of all of the annoyances that had always bothered me. On the client, I implemented data objects that presented interfaces to the developers but generated straight SQL for all DBIO, just using a momentary database connection. Once we had the system up and running, I did a stress test on it by spawning new user sessions, each one doing a database hit every five seconds, on a server that only had a 5 connection license. I got up to over 10k client sessions before I gave up trying to crater it. I was so proud of that thing.
In prior lives I filled most of these roles at the same time. It is nice to back away, and concentrate on one at a time for a change.
I would think that a great opportunity to build things right the first time around. I've more often than not had to cleanup after little to no maintenance or security practices. On top of that, being involved in the design and implementation gives much greater insight into how all the pieces work together.
Viewing 6 posts - 1 through 5 (of 5 total)