My experience with Oracle has been largely limited to "relatively satisfied user of the school CS department's tiny DB". Recently, I had the joy of installing the RDBMS to a VM for some prototyping. If managing the thing is as bad as installing it... oh boy.

Since I now have Oracle DBA experience (in much the same way that someone hit by a bus has bus driver experience), I've been reassigned to a DBA position starting next month. Great, so now I'm responsible for managing an enterprise-wide Oracle setup? Job changing is out of the question, for now.

So, I start off as an idiot DBA. Where should I begin my quest for knowledge? I've read this forum and others for years, so I've seen plenty of idiot DBA mistakes. I don't want to be that guy.

SwampJedi:

Where should I begin my quest for knowledge?

 

Two places:

1. the business. Ascertain exactly what duties they expect of you. It doesn't need to be specific, just what situations will cause people to ( yell at | blame point fingers at ) you.
2. training courses. Find courses which fulfill these requirements, attend and pick brains of tutor and others around you for info. If the business is serious about you being an OraDBA, then they should invest serious money in bringing your skills up to the required capability.
3. the previous DBA. What did they do, and how? Look for internal documentation.

 

Cassidy, thanks. I suppose I left out the one fact to rule them all - this is a government position. Oh, and this is a government job that, until recently, was contracted out. Chances are that means even more WTFs are to come.

That doesn't really impact #1, which is at the top of my list as well. The "great" thing is that no matter how badly I mess up, I'm not going to lose my job. But I don't want to mess up.

There's no training money. :-( I will check and see if internal documentation exists. I have a sneaking suspicion that it does not, because the boss (who has been there only a few months) is really pushing for formalized process development.

Any recommendations for books/guides that can at least move me from "idiot" to "yeah I've heard of them thar DB things before"?

SwampJedi:

this is a government position. Oh, and this is a government job that, until recently, was contracted out. Chances are that means even more WTFs are to come

 

IME, for that particular case, chance approaches 100%.

SwampJedi:

There's no training money

Then the position doesn't require anyone skilled, ergo it doesn't matter too much if you fuck up. Yeah.. that's me being passive-aggressive-pissy-mindset again, but you get the picture: if your organisation doesn't value properly training you to raise your capabilities then they can't see the position as being particularly business-critical.

Edit: since this was a contracted position... surely there's money freed up from removing the contractor, eh? And do they honestly think that a highly-paid skilled contractor[1] can be replaced by an untrained internal resource and still maintain quality of service? 

SwampJedi:

Any recommendations for books/guides that can at least move me from "idiot" to "yeah I've heard of them thar DB things before"?

Yeah.. my training course manuals. Sorry if this sounds like blowing my own trumpet, but when I teach Oracle DBA courses I'm not really teaching how to use tools, I'm turning them into DBAs - I don't teach database administration, more preach what's expected of them, why they need to do this stuff, what would happen if they didn't.

The underlying technology is almost incidental: they begin to see it as a means to an end, that there's a large amount of business data that needs to be made available to specific people at specific times and they simply manage that technology to fulfill business requirements now and for the forseeable future.

Now, if you want to pick my brains over this stuff, I'm happy to lend a hand. But I strongly recommend that you get some formal training in, even if it means getting in that contractor to show you the basics. DBA stuff, expecially in the Oracle world, isn't something easily gained by theory alone.

[1] I'm making assumptions on the premise that the position would have been internally-sourced from day one if they could.. but they didn't because they originally couldn't.

SwampJedi:

Where should I begin my quest for knowledge?

The font of all Oracle knowledge, of course!

SwampJedi:

Any recommendations for books/guides that can at least move me from "idiot" to "yeah I've heard of them thar DB things before"?

Not from me, but be aware of the 'Dunning–Kruger effect' (google/wiki) - the bright idea you get from the books/guides you want to implement now must be tempered by the fact that there's evidence out there that what you're about to implement will end up on this site.

Sobering. I haven't seen any of my work here, though I know some of my production code deserved to be posted.

Cassidy - I appreciate your approach. Teaching someone the tool/technology isn't really accomplishing much. That's probably the root cause behind many WTFs. It's almost a cargo cult mentality. You need the why behind the what!

Hopefully I can convince them to come off some training cash.

SwampJedi:

You need the why behind the what!

 

I believe the "why should ths be done?", "when should it be done?", "who should do this?" and "what happens if it doesn't get done?" all serve to put the "how is this done" into business context.

Without it, you're just learning by rote. Kata has a place, and learning where that place should be is instrumental to cementing the concepts.

SwampJedi:

My experience with Oracle has been largely limited to "relatively satisfied user of the school CS department's tiny DB". Recently, I had the joy of installing the RDBMS to a VM for some prototyping. If managing the thing is as bad as installing it... oh boy.

Since I now have Oracle DBA experience (in much the same way that someone hit by a bus has bus driver experience), I've been reassigned to a DBA position starting next month. Great, so now I'm responsible for managing an enterprise-wide Oracle setup? Job changing is out of the question, for now.

So, I start off as an idiot DBA. Where should I begin my quest for knowledge? I've read this forum and others for years, so I've seen plenty of idiot DBA mistakes. I don't want to be that guy.

 

 

Oracle Corporation is very big hearted to provide service of Tom Kite http://asktom.oracle.com/ is URL for his service. If in doubt, you can always ask questions and depending on Tom's mood he'll answer. Make sure you don't use sms type language like "u", "b4" etc, or else he will laugh at you.<br/>

You can also ask me since I am engage in act of doing data object delivery. It sound like delivering babies, but it is more complicate than that.<br/>

 

Awesomely enough, all of the contract employees packed up yesterday due to the contract expiring. There goes all of my help! Oh, I don't have accounts yet? Oh well.

 So I'm apparently the LEAD DBA. That's TRWTF.

SwampJedi:

Awesomely enough, all of the contract employees packed up yesterday due to the contract expiring. There goes all of my help! Oh, I don't have accounts yet? Oh well.

 So I'm apparently the LEAD DBA. That's TRWTF.

 

 

If you think you're in trouble, think of person leading project. That will make you feel better. Why did management not feel to renew expiring contracts?<br/>

 

SwampJedi:

So I'm apparently they're expecting me to take over the role of LEAD DBA without any formal training. That's TRWTF.

 

FTFY.

When asked some DBA stuff, either shrug and point at the departing contractors with "they know this stuff, I don't" or "I'll take on that role after I receive the appropriate training required to properly fulfil the responsibilities expected of me."

TRWTF appears to be no proper handover process - you're losing all those contractors and by the time you realise you needed to pick their brains over something, they've already left.

Of course, if they (and your organisation) practised decent config management and had heaps of documentation for you, that's not an issue. But somehow I get the impression this could be lacking.

SwampJedi:

Awesomely enough, all of the contract employees packed up yesterday due to the contract expiring. There goes all of my help! Oh, I don't have accounts yet? Oh well.

 So I'm apparently the LEAD DBA. That's TRWTF.

I hope you do better than your predecessor, Admiral Piett.

Amusingly, things have gone better for me than for the previous lead. I managed to close some tickets that had been open a year or more. Learned a lot by drowning for the last 6 weeks.

But.

I just got promoted, back to software (Lead SE for the org, in fact). I'd say I got "Dilbert'ed", but DB things have noticably improved under my watch.