It's often the case for a technical analyst to have occasion to reach beyond their original job description to solve problems. Perhaps, though, no more so than a database administrator, who is tasked with managing what is often the focal point of a business -- data -- a point where every technical discipline can converge.
I suppose it would be helpful to take a step back and ask the question: what does a database administrator do?
There are as many answers to that question as there are database administrators. You've probably had to think about answering that question for a layperson before, and come to the realization that there just isn't a general answer. You probably ended up answering the question "what do I do as a database administrator?" to avoid giving some sort of cop-out answer like "manage databases" after having a puzzled look on your face for several seconds.
Maybe all you do is make sure all the data is backed up and recoverable, and respond to alerts when those processes are in trouble. Maybe all you do is analyze traces to make performance improvements. Maybe all you do is write report queries for the people wearing suits.
More typically, though, you do many different things at different times -- or all at once -- to solve a problem. Analyze a performance trace to determine why a report query is slow, and find out that while the code could be improved, there's a latency issue with the storage network. That sounds a lot more like it. Sometimes the lines drawn between technical disciplines become so blurry they disappear altogether.
Everyone has their own set of likes and dislikes, and of course that isn't limited only to your career. It's a set that's constantly changing -- sometimes gradually, sometimes rapidly -- as you experience things for yourself.
In the field of information technology, there are so many different areas to explore, even when only considering what's involved with database administration specifically. Programming, hardware, storage, networking, and more -- the expanse of knowledge is vast and growing every single day, and so it's becoming more and more difficult (if not impossible) to be an expert in all of them.
Practically speaking, I think abandoning the idea of becoming that all-knowing expert is the only reasonable approach. That isn't to say that goals should be abandoned as well; my suggestion is simply to focus, or re-focus. Concentrate on the one or two areas where your natural aptitude and positive attitude intersect, and hold an interest in many of the other major areas, even if you don't consider some of them to be particularly interesting.
While that sounds a bit like punishment, the broader your exposure is to different subjects, the better able you'll be able to not only solve a wider variety of problems, but you'll have real communication ability with everyone in your IT department, which is truly valuable.
Conversations about VLANs and ORMs take on real, practical meaning as they affect the database, your primary responsibility. Even a small amount of understanding of just the subject jargon can go a long way.
Those who become database administrators often start in a peripheral field of study, usually either software development or system administration. Like the answer to "what does a database administrator do" varies, so are the paths to be a database administrator.
It's somewhat ironic that people struggle with the question "how do I become a database administrator" (there is no database administrator college program), yet database administration has numerous peripheral technical fields, making it possible to transition from a wider variety of traditional roles.
I think of it more as building a foundation on which to rely, so it should be a very strong foundation. Not necessarily as a fallback (although that's probably a good plan), but more as a deep-level area, as I mentioned. Above all else, though, you have to bring your problem-solving and information synthesizing skills to the table. Peripheral knowledge is far less useful without the ability to practically apply it in some way.
I suppose the point of this post is to encourage you to reach out into some of the peripheral subjects of database administration. It will only help your career.
Make it a habit, too, even if only once/week. A great way to proactively do this is to subscribe to a newsletter such as Database Weekly, which delivers a wide cross-section of database-related topics directly to your inbox.
In the comments, let me know what your experiences are with needing to deal with a wide variety of subjects. Did you transition to database administration through a non-standard technical field?