There is a definite need for people with detailed knowledge of mission critical apps and it's optimal when DBA's and System Admins are wired in!
> the role I play doesn't seem to have any technical boundaries Boundaries are things that aggressive DBA's want to break through. They intrusively stick their noses into development, systems admin, networks, and applications. Why? Because it affects database performance. Since the database touches so much it only stands to reason that DBA's stretch and challenge the boundaries. Here's a link from Oracle Magazine that addresses this at some length. http://www.oracle.com/oramag/oracle/99-Mar/index.html?29cov.html Steve Orr Former Californian well rested in Montana -----Original Message----- Sent: Thursday, May 30, 2002 11:57 AM To: Multiple recipients of list ORACLE-L I know I'm probably going to regret replying to this thread. I'm one of those people who spent years as a programmer...and wound up somewhere in between applications and tech support because I couldn't get the tech support I needed. When we got "SAP'd" in '93, I finally gave in to becoming a so-called "DBA" to keep the legacy systems running (not Oracle based) AND keep the SAP project afloat. So I'm probably one of those SAP "babysitters." I would love to be able to hire a "development" or "applications" DBA (we also have non-SAP Oracle databases) but the skill set I need in an individual to actually reduce my work load is much broader than the typical Oracle "development" or "applications" person. I know there can be exceptions, of course, but I haven't found "development" or "applications" people to be too concerned about the context in which a database lives let alone know what IT auditors would be looking for. I mean, the role I play doesn't seem to have any technical boundaries because, again, anything that can impact the application (be it SAN, OS, network, presentation layer, security, hardware, maybe even Sun spots...) is of concern to me. On the other hand, a DBA without an understanding of the demands put on developer/applications people is a problem, too. Or maybe I needed to whine a bit because I've been up at 2am and 5am a couple of days in a row. Sleepless in California, Kip Bryant |I'd take that pay differential thing with a grain of salt. |The definitions for Production DBA's, Apps, DBA's, and Development DBA's are |merely organizational interpretations. Each organization custom creates |these "titles" so PHB's can put labels on people. |In many cases a production DBA is merely a database babysitter and a |Development/Apps DBA requires higher skills for the overall architecture. In |other cases an apps "DBA" may just be someone who knows how to maintain a |particular 3rd party application but their knowledge of the database engine |is suspect. I once knew an "HR Database Administrator," AKA Apps DBA, who |knew nothing about databases but lots about some weird, off the wall, |non-mainstream, proprietary HR application. This person's skills were not |marketable but their title was. ;-) |Aspiring chief cook and bottle washer, |Steve Orr -- Please see the official ORACLE-L FAQ: http://www.orafaq.com -- Author: Orr, Steve INET: [EMAIL PROTECTED] Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051 San Diego, California -- Public Internet access / Mailing Lists -------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
