Re: Noob Oracle Question

CJM wrote:
> "neo" <superk7_at_collegeclub.com> wrote in message
> news:1155938131.520818.313660_at_h48g2000cwc.googlegroups.com...
> > Remember guys, he DID already state that he was a noob.
> >
> > AND this is not a production database, they more than likely haven't
> > even migrated any data into it.
> >
> > I don't understand why you are scolding someone for doing something
> > they are CLEARLY asking you how to do.
> >
>
> Thanks for the support.
>
> But for the record... I'm an Oracle noob, but I'm an experienced developer
> and usenet participant, and I've seen for too many smart-asses pouring scorn
> on a poster when they are asking a reasonable question to take actually take
> any such shit myself. So to be clear... if anyone has a point to make, just
> make it. Don't assume anything.. just state your case. If you disagree with
> a post, say so, and explain how your views differ. Save the wise-cracks,
> because there is only you who thinks it's clever. And it looks silly months
> and years on when the next guys trawl through the archives looking for help
> on a similar subject.

You might want to reflect on the issue of those who have seen the same issues over and over ad nauseum. I agree it would be better to politely lead noobs toward the correct path. If that worked. _I've_ tried to make it work (like http://www.dbaoracle.net/readme-cdos.htm ), and it often does, though when it does, one tends to not get feedback about it (unlike a class instructor, who can get immediate feedback). This group (and it is not alone) gets lots of people who have difficulty letting go of the way they've learned to do things, and for them it doesn't work. They need their attention gotten. I'm continually amazed at how often the more brusque posters get it right.

>
> Anyway, back to the topic. Of course, this is not a production DB; this is
> not even the latest test DB. It *is* a populated DB but then again we are
> using to develop migration routines as well.
>
> To answer Daniel & Joels recent points: Yes, this is a major ERP
> implementation. But I'm not doing it. In theory, we have purchased a system
> suitable for our needs; in practice, it doesnt begin to come close to
> fitting our business perfectly. Amongst other things, we have found one area
> where the system is so poorly designed that we are having to take that
> function outside the system - hence I am trying to develop a bolt-on
> mini-application to do this. If it were up to me, we would be getting the
> supplier to mod this, or ideally, we would have identified this problem at
> the outset, and taken a different course of action earlier.
>
> Is it naive of my management to expect me to implement such as system with
> no training or previous exposure to Oracle? Of course. Is this kind of thing
> a rarity? Not even close - not only does it regularly happen in our
> organisation, but it happens in many/most organisations too - we hear about
> it all the time. Does it happen in yours? If not, I envy you, because I've
> faced the same saga in every job I have had. Shit happens. We can object,
> but ultimately we have to deal with it.

I used to think a good way for those thrust into a new software environment is to thrash around in it for a couple of months, then take formal education. That way, you hit the ground running in the formal education, at least in some little parts where you made some mental connections. I don't think that anymore (at least for Oracle), since so many people are so ingrained in ways that are just wrong from the Oracle viewpoint, and you can make things work while continuing bad habits. This institutionalizes the mess. It's not just cases of one developer in a company, either, most of the ERP systems out there show this too.

In the real world, development becomes production, good or bad, so you and everyone after you are better off cutting off the bad ASAP.

>
> Bearing in mind that I am the sole *dedicated* devoper in the company (there
> are two others who develop in certain areas for part of their roles), don't
> you think I should have been trained in the fundamentals of Oracle at the
> very minimum. Of course, I should...

Print out the concepts manual and read it. Then read it again (especially the locking and consistency parts).

>
> Do you not think that we should have perhaps given greater weight to
> solutions based on SQL Server DBs given that our company has a base of
> experience in this technology? I would have...

Since I'm biased towards MRP/ERP, and see cases where scalability is an issue, I'd say I agree with you for little home-grown projects but not for this.

>
> Do you not think that the person with the most RDBMS skills and experience,
> and the guy who primarly supports the the dozen or so SQL Servers, should be
> trained up to adminster the Oracle DB. Again, I would have...

I have a little more difficulty with this. From what I've seen (and I'd been interested if others have seen otherwise), Sybase-derived DBA's tend to place great stock in memorizing supplied SP's, and perhaps writing some. While some Oracle shops may do the same thing, I don't think that should be the primary skill of an Oracle DBA. In the case of bringing an Oracle ERP solution into a non-Oracle shop, I'd say it would be most important to have a "functional DBA" experienced in that solution, and at least have available an experienced "technical DBA." They should then transfer knowledge to an inhouse DBA if they aren't going to be there permanently. A major problem is that since ERP solutions aren't often written properly from a DBA standpoint, whoever is dealing with it has to understand both how it is supposed to work and how to make it actually work. I've seen very experienced DBA's _not_ be able to deal with this. Trying to comprehend it all as a noob is just too much to ask.

The training out there is variable, too. (huge understatement)

>
> However, 'the management' have made their decisions and we're all stuck with
> them. So now I need to do my job.
>
> As with any technology, you start off wielding a sledgehammer, you progress
> through some other tools, until (hopefully) you are capable of handling a
> scalpel with skill. I would hope that I am at the scalpel stage with SQL
> Server, but after two days of investigation with Oracle, I can still barely
> lift the sledgehammer. Of course, by experience with other RDBMS's will
> stand me in good stead eventually, but there are plenty of conceptual
> differences between each DB, before we even get to the simple syntax
> problems [e.g. Why the hell isnt there a TOP keyword in Oracle??].

Get yourself Tom Kyte's books ASAP. Skip the sledgehammer phase. He starts off with several chapters explicitly geared towards developers coming into the Oracle world.

I used to be worried that my work cleaning up other people's messes would be going away with the easier management of the newer versions of Oracle, but I seem to have been a bit pessimistic. Or is that optimistic?

>
> So next time I ask a question, can you all please try your best to answer
> *my* question. We can always create another thread on management
> best-practice and other peripheral issues. But meanwhile, I have a difficult
> job to do at short notice, and would appreciate constructive help from my
> peers.

I second this.

jg

--
@home.com is bogus.
http://www.ds9r.com/dlog/wp-content/images/easter.jpg