Getting experience is always the key. But I see many people doing application support of some system, with a database backend, yet they do no SQL with it. For example, if I was a network engineer curious about SQL, I would get a trial license of SQL server, import a the CDB file from a router and start writing queries against it. Look for trends in time, dropped packets, problems on the network ... Maybe you would even find something that you need to adjust on your network. Impress your boss with a graph of trends on the network. I started out many years ago doing data entry, there were no reports on the system and nobody to do them, so I learned OS-400 query.

I agree I don't want someone to rattle off DBCC commands - but I would want them to know about books online... Knowing where to go to get answers is extermely valuable and I expect to get responses like "I don't know the answer to that question, but I would look it up on BOL".

If your relying solely on the GUI to administer your servers, your missing out on many functions. I've had servers running so badly that the GUI will not function, if that was all I knew I would never have been able to kill any process that were bringing the server down.

The issue of too much experience and in essence pricing yourself out of a position is a problem. I don't know the answer to that issue - start turning down raises so you remain competitive? Or start lowering your salary requirements - or maybe accept that you make a lot and need to enjoy the current diggs?