1 2 3 4 Previous Next 45 Replies Latest reply: Oct 9, 2012 6:32 AM by user8983130 RSS

    Are the oracle DBa's seeing an end to their career

    user8983130
      It's been 2-3 years i am working as an oracle dba in a mid range shop and i was pretty happy with it. After having the satisfaction , I was always worried about the future of an oracle dba. I always heard sql server and db2 are much much better than oracle as they are less complex to administration and their cost is less. Though the oracle people would talk about performance and scalability but with the recent releases , those db have overcome those problems. The problems for oracle dba are coming from several ways:

      1.Companies are shifting for sql server or db2 as for low cost and low required of man power.

      2.Oracle itself becoming automated.

      3. Company like IBM offering main frame solution with free db2 database for the entire data center.

      4.With the concept of Cloud computing storage would be third party location , where few employee can take the responsibility.

      And..many moreeee...

      It gives me a COLD feelings what would i be doing in 3-5 years from now and how could a dba would evolve himself with the change??? I hope this time i am not right.. all the points that i showed is wrong...

      Regards,
        • 1. Re: Are the oracle DBa's seeing an end to their career
          Alex Fatkulin
          All offer some of my views on these.

          #1 is actually not as clear cut as many may think. Look at Oracle SE/ONE prices. These are actually more than competitive.

          #2 the trend has been going for more than a decade now. DBAs need to move into higher value niches. Think manufacturing. Why do you think Apple has "Designed in California assembled in China" on their products? With the cloud most of the provisioning and patching will likely see deminishing presence outside of a vendor-controlled eco space. So if you are a DBA who only knows how to patch and install then yes... And even that is not a clear cut as increased system complexities may in fact put more demand out there. On the other hand pay-per-use models make performance even more important so expect these skills to be in a even higher demand than today.

          #3 customers look at the total solutions costs. There is probably a lot of context in there. One would think that throwing in your software for free means it provides no value? :)

          #4 see #2
          • 2. Re: Are the oracle DBa's seeing an end to their career
            Aman....
            When 10g was releases, this was the question that all were asking and since I am in a profession of training,I got this question in every 10g new features session of mine. And so far, I haven't seen any dba in my knowledge to be out of job because his/her company has got 10g or 11g . If they are supposed to be out , that was beacuse of some other reason like market being tight but as they were good, tehy got absorbed in other companies quite soon. So the dba's job is going away, I won't be sayinng that's a truth.

            >1.Companies are shifting for sql server or db2 as for low cost and low required of man power.

            So? Just because soething is easy,doesn't mean that its better too. How about the restriction that you can't have sql server only for Windows platform? How many data centers you know which are running pure windows only ? The same goes for DB2. I am not a SQL Server or DB2 guy but from the reading about them in comparisons to Oracle, I am not going to put my money over them, at least not right now especially when the new release of db 12c is hopeful to be out soon. And then there is not just database alone that Oracle has to offer at the moment. EM 12, Exa* family of servers along with the db are proving to be a very good and strong product line and it won't be easy if not impossible for others to follow or beat it.
            2.Oracle itself becoming automated.
            Automation doesn't mean a human is not needed. If you are following 10g and 11g automations , how many shops you have seen which are running the memory management purely automatically without dba's looking at it or how many dba's you have seen tuning queries just by implementing what the tuning advisor tool has to say? With automatation things become ever more harder because less is told to you and that means, you need to be knowledgeable even more than before.
            3. Company like IBM offering main frame solution with free db2 database for the entire data center.
            Again, free does not becomes its good.
            .With the concept of Cloud computing storage would be third party location , where few employee can take the responsibility.
            I am not sure that where you have read it but AFAIK, only Amazon is offering such service at the moment. Oracle's cloud computing would be rolled out hopefully in this week at OOW . So only then we shall come to know what is really Oracle is offering in the cloud computing area.

            I shall just say in the last that if you are a good and knowlegeabe Oracle guy, you wouldn't be thrown out just because there is an automated release of database.

            HTH
            Aman....
            • 3. Re: Are the oracle DBa's seeing an end to their career
              Osama_Mustafa
              you don't have to be worried . Maybe there's Other competitor , and you will find this in any market . But I will Goes With My lovely Database Oracle . even i am certified Db2 10.1 But I don't see Features in DB2 That Oracle Gave you . its little Expensive but you will have more features.

              the big difference you will notice is price and include to all of this
              DB2 requires more Memory
              -Oracle leads DB2 in transaction Benchmark testing
              Oracle Function-based indexes, Domain indexes
              DB2 Block indexes, Dimension block indexes
              • 4. Re: Are the oracle DBa's seeing an end to their career
                user8983130
                Any other thoughts????!!!
                • 5. Re: Are the oracle DBa's seeing an end to their career
                  EdStevens
                  user8983130 wrote:
                  Any other thoughts????!!!
                  If you want to come in and push the same buttons every day for the rest of your life, you will have a very short career. And it doesn't matter what label those buttons have on them.

                  If you perceive your job as defined by some title or by today's task list, you will have a very short career. And it doesn't matter what that job title or task list is.

                  If you perceive your job as helping your company succeed by bringing every skill and every bit of knowledge you have to help solve whatever problem is presented, and you are constantly trying to expand those skills and knowledge, you have only to worry about working for companies that try to define YOU by an arbitrary job title, and thus constrain you.

                  I've been in this business over 30 years. I started off as a COBOL programmer on IBM mainframes. Even though my university degree was totally unrelated to IT, I tried to be the best and most knowledgeable COBOL programmer in the shop. To do so, I was always trying to peel back the layers of abstraction just so I'd have a better understanding of WHY things behaved the way they did. As a result, I've had a couple of major shifts in my career, and none of them were planned. I never said to myself "I think I'll go take this course, get this cert, and change my career". No, the changes came naturally when my employer needed a new skill set and saw that I was the guy who was an adaptable self-learner, and simply gave me new assignments.

                  Actually, I wasn't even making an overt decision to "help my company succeed". I've just always been curious to figure out what's happening at the next layer of abstraction below where I'm working, what's the other side of all those interfaces, trying to solve a puzzle. I've just been blessed that that curiosity has aligned with the interests of someone offering a pay check.

                  As to your opening question "Are the oracle DBA's seeing an end to their career?" .... at my age, I certainly hope this Oracle DBA is seeing an end to his career in a very few years. Not because I become obsolete, but because my retirement investments pay off .... ;-)
                  • 6. Re: Are the oracle DBa's seeing an end to their career
                    jgarry
                    Most companies care more about apps than db engines. Some apps can run on more than one engine. Since that is technically a non-optimal solution which slops over onto what users care about, there is some pressure to bind the app and db more closely. So you see SAP pushing whatever, Oracle pushing fusion, and so on. For the dba, this means a choice: become an apps dba or dive deep into specialized tuning.

                    Vendors are pushing customers to pick their all-encompassing solution. Customers care more about apps, so either they buy a bunch of apps and try to loosely couple them, or buy the soup-to-nuts solution and buy additional apps, or both, in the common case of an evolving company IT department. For the dba, this means a choice: specialize in the tech stack in the soup-to-nuts solution, or take on all the stacks, as well as integration issues.

                    The cloud in some sense simply means another technology stack, in some cases with other dba's in control you have to deal with, in others more virtualization issues locally.

                    Even the old-skool dba's aren't completely going away - there are companies looking for them, with the requirement to travel a lot, no telecommuting, presumably because all those companies with stable or not yet upgraded systems need bodies. Putatively obsolete skills aren't really obsolete, they just become scarce and sometimes in-demand.

                    A lot depends on luck, and you make your own luck by being prepared when opportunities fall in your lap. It's not an end to a career, just some detail transformation. And even if I'm totally wrong, there's always development.
                    • 7. Re: Are the oracle DBa's seeing an end to their career
                      Mark Malakanov (user11181920)
                      In next N years ultimately everything in RDBMS will be automated.
                      This is a common trend and Oracle is leading flagship in it.
                      Ultimate goal, as I see, is to eliminate DBA, minimizing cost of ownership.
                      This will attract business to such products - self-managed software.

                      I do not see it to happen tomorrow, though. But it is going there.

                      Many here will argue with me, but look of the definition of DBA
                      http://sqldbpool.com/2008/12/22/dba-roles-and-responsibilities/
                      >
                      DBA Responsibilities

                      Installation, configuration and upgrading of Microsoft SQL Server/MySQL/Oracle server software and related products.
                      Evaluate MSSQL/MySQL/Oracle features and MSSQL/MySQL/Oracle related products.
                      Establish and maintain sound backup and recovery policies and procedures.
                      Take care of the Database design and implementation.
                      Implement and maintain database security (create and maintain users and roles, assign privileges).
                      Database tuning and performance monitoring.
                      Application tuning and performance monitoring.
                      Setup and maintain documentation and standards.
                      Plan growth and changes (capacity planning).
                      Work as part of a team and provide 7×24 supports when required.
                      Do general technical trouble shooting and give consultation to development teams.
                      Interface with MSSQL/MySQL/Oracle for technical support.
                      ITIL Skill set requirement (Problem Management/Incident Management/Chain Management etc)
                      >

                      Then lets look at them one by one:
                      Installation, configuration and upgrading of Microsoft SQL Server/MySQL/Oracle server software and related products.
                      How often Installation happens? Once for one new app. Usually app vendors have recommendations that DBA should follow. So, what is DBA's role here? Start installer and to follow.
                      Configuration and upgrading will be more and more automated.
                      Evaluate MSSQL/MySQL/Oracle features and MSSQL/MySQL/Oracle related products.
                      Again, how often? When new App is about to be created and designers need to choose which DB they will need.
                      Establish and maintain sound backup and recovery policies and procedures.
                      Again, how often yo need to establish policies and procedures?
                      Backup itself is 100% automated already today. Recovery is close to 100%.
                      Most of enterprise backup software support backup and recovery of major RDBMSs.
                      Just specify a date "from" and click Go.
                      A little bit complex with RMAN. You have to type(!) RESTORE DATABASE; RECOVER...
                      Take care of the Database design and implementation.
                      Where? Only in development shops.
                      Implement and maintain database security (create and maintain users and roles, assign privileges).
                      Centralized enterprise security (Domain etc) are in use. Many apps have their security and use basic RDMS security to login App running user.
                      Database tuning and performance monitoring.
                      Greatly automated. Ultimately will be 100% automated.
                      Application tuning and performance monitoring.
                      There are enterprise solutions for monitoring. Also Oracle has Grid Control.
                      Application tuning can be done by app vendors. DBA cannot tune App itself. It may only modify some things in DB that will perform better. And this will be automated.
                      Setup and maintain documentation and standards.
                      How often?
                      Plan growth and changes (capacity planning).
                      Well, DBA should do it. But, again, how often?
                      Work as part of a team and provide 7×24 supports when required.
                      Where such 7×24 support policy exists.
                      And what from above should be supported during a night by a human?
                      I see just a restore/recover DB, because a human should make a decision "From which Date".
                      Do general technical trouble shooting and give consultation to development teams.
                      Yes, in Dev shops. Most of shops are not development shops, though may do custom and ad-hoc reporting and small app development. Do they need a dedicated DBA for this? I doubt. Either a developer will be (self)trained to do some DBA's tasks or DBA will become a SQL developer in that team.
                      Interface with MSSQL/MySQL/Oracle for technical support.
                      Oh yeah... :)
                      ITIL Skill set requirement (Problem Management/Incident Management/Chain
                      Sure, two days of training to know basics of ITIL to understand what manager of Helpdesk (Support and Incident Management Team) is talking about.

                      So, I see DBA should go in of 3 directions:
                      1. Very deep technical expert that can help in some rear and difficult cases. How many of them will be needed?
                      2. SQL/ETL/etc Developer. There is not much automation in software development yet.
                      3. DB Design and Architecture. How many of them will be needed? May be more that #1.
                      • 8. Re: Are the oracle DBa's seeing an end to their career
                        jgarry
                        user11181920 wrote:
                        In next N years ultimately everything in RDBMS will be automated.
                        This is a common trend and Oracle is leading flagship in it.
                        Ultimate goal, as I see, is to eliminate DBA, minimizing cost of ownership.
                        This will attract business to such products - self-managed software.
                        I think that is a marketing dream only.
                        ...
                        Establish and maintain sound backup and recovery policies and procedures.
                        Again, how often yo need to establish policies and procedures?
                        Backup itself is 100% automated already today. Recovery is close to 100%.
                        Most of enterprise backup software support backup and recovery of major RDBMSs.
                        Just specify a date "from" and click Go.
                        A little bit complex with RMAN. You have to type(!) RESTORE DATABASE; RECOVER...
                        There is a Perform Recovery link in dbconsole, including various objects and flashback.

                        >
                        Take care of the Database design and implementation.
                        Where? Only in development shops.
                        This I disagree with, unless you have a pretty broad definition of development shop.

                        >
                        Implement and maintain database security (create and maintain users and roles, assign privileges).
                        Centralized enterprise security (Domain etc) are in use. Many apps have their security and use basic RDMS security to login App running user.
                        Someone still has to do it.

                        >
                        Database tuning and performance monitoring.
                        Greatly automated. Ultimately will be 100% automated.
                        Not convinced, for the foreseeable future.

                        >
                        Application tuning and performance monitoring.
                        There are enterprise solutions for monitoring. Also Oracle has Grid Control.
                        Application tuning can be done by app vendors. DBA cannot tune App itself. It may only modify some things in DB that will perform better. And this will be automated.
                        I also don't agree with this, as the database features tend to be ahead of the app vendors. Way too expensive and time consuming to write from scratch, so there is always elderly stuff.

                        >
                        Setup and maintain documentation and standards.
                        How often?
                        It's that maintenance part...

                        >
                        Plan growth and changes (capacity planning).
                        Well, DBA should do it. But, again, how often?
                        There was a time you could confidently say "this system will last 5 years." I don't see that any more. I see continuous ups and downs in project activity, new things getting added, major upgrades.

                        >
                        Work as part of a team and provide 7×24 supports when required.
                        Where such 7×24 support policy exists.
                        And what from above should be supported during a night by a human?
                        I see just a restore/recover DB, because a human should make a decision "From which Date".
                        I kind of agree with this, but as I see the role expanding beyond the database (and with actual worldwide apps), I kind of don't.

                        >
                        Do general technical trouble shooting and give consultation to development teams.
                        Yes, in Dev shops. Most of shops are not development shops, though may do custom and ad-hoc reporting and small app development. Do they need a dedicated DBA for this? I doubt. Either a developer will be (self)trained to do some DBA's tasks or DBA will become a SQL developer in that team.
                        This is put much better than above. That is what I do (well, very little SQL these days). I doubt it is that rare. I've long thought a 10:1 dev:dba ratio seems to be the natural, whether or not there are more than 10 developers, and I haven't seen a real change. I have seen strange management of human resources...

                        >
                        Interface with MSSQL/MySQL/Oracle for technical support.
                        Oh yeah... :)
                        :-)

                        >
                        ITIL Skill set requirement (Problem Management/Incident Management/Chain
                        Sure, two days of training to know basics of ITIL to understand what manager of Helpdesk (Support and Incident Management Team) is talking about.
                        This is kind of interesting, I see such a difference between my issue domain and the general help desk issues, having them interleaved is always a problem.

                        >
                        So, I see DBA should go in of 3 directions:
                        1. Very deep technical expert that can help in some rear and difficult cases. How many of them will be needed?
                        That was my initial thought, then I realized, all the optimizer issues still need human involvement. I guess we can just agree to disagree about how automated that can get, I still foresee the features outrunning the tools.
                        2. SQL/ETL/etc Developer. There is not much automation in software development yet.
                        This is correct, yet some would have you believe it is not true. What happens is someone comes up with something that works up to some point of complexity. The things that work to a higher complexity are... more complicated! So you get all these framework messes.
                        3. DB Design and Architecture. How many of them will be needed? May be more that #1.
                        Could be, kind of depends on the growth of other products (like the hadoops etc.), and how well standardization of existing products work, and whether you count ongoing maintenance.
                        • 9. Re: Are the oracle DBa's seeing an end to their career
                          EdStevens
                          user11181920 wrote:
                          In next N years ultimately everything in RDBMS will be automated.
                          This is a common trend and Oracle is leading flagship in it.
                          Ultimate goal, as I see, is to eliminate DBA, minimizing cost of ownership.
                          This will attract business to such products - self-managed software.

                          I do not see it to happen tomorrow, though. But it is going there.
                          Yeah, well 30 years ago the experts were predicting the end of the need for programmers (the old term for 'developers'). "End User Computing" would put the power in the hands of the business users and eliminate the entire IT department. No I'm not exaggerating. That was the prediction. And people like you were insisting it would come to pass.

                          You don't even have to go that far. Look at the predictions for the 'paperless office' . . .

                          Many here will argue with me, but look of the definition of DBA
                          http://sqldbpool.com/2008/12/22/dba-roles-and-responsibilities/
                          >
                          DBA Responsibilities

                          Installation, configuration and upgrading of Microsoft SQL Server/MySQL/Oracle server software and related products.
                          Evaluate MSSQL/MySQL/Oracle features and MSSQL/MySQL/Oracle related products.
                          Establish and maintain sound backup and recovery policies and procedures.
                          Take care of the Database design and implementation.
                          Implement and maintain database security (create and maintain users and roles, assign privileges).
                          Database tuning and performance monitoring.
                          Application tuning and performance monitoring.
                          Setup and maintain documentation and standards.
                          Plan growth and changes (capacity planning).
                          Work as part of a team and provide 7×24 supports when required.
                          Do general technical trouble shooting and give consultation to development teams.
                          Interface with MSSQL/MySQL/Oracle for technical support.
                          ITIL Skill set requirement (Problem Management/Incident Management/Chain Management etc)
                          >
                          Well, that's ONE "definition" of a DBA. It's far from "the" definition.

                          I'll tell you what. I've actually sat on committees that drew up lists like that. I can tell you first hand that while a lot of things on the list may look legit, there is also a lot of pressure just to fill up the list with as many things as possible in order to justify head count to the bean counters. You could just as well add 'weekly cleaning of the left-hand smoke shifter.'
                          Then lets look at them one by one:
                          Installation, configuration and upgrading of Microsoft SQL Server/MySQL/Oracle server software and related products.
                          How often Installation happens? Once for one new app. Usually app vendors have recommendations that DBA should follow. So, what is DBA's role here? Start installer and to follow.
                          Configuration and upgrading will be more and more automated.
                          Except the app vendor left out critical details they didn't think were critical because they don't understand the database. Or have bogus 'requirements' because they don't understand the database. Or their recommendations were based on how they did it in their pristine development lab and they never even knew about critical dependencies that might not exist outside of their lab.

                          Week before last I spent 50 hours working on installing a new database based on the app vendor's specifications ....
                          Evaluate MSSQL/MySQL/Oracle features and MSSQL/MySQL/Oracle related products.
                          Again, how often? When new App is about to be created and designers need to choose which DB they will need.
                          And then they proceed to develop on rdbms-A using best practices they learned from rdbms-B -- which turn out to be worst practices on rdbms-A. And only when they go live do they discover that their design doesn't scale because they tried to re-invent (poorly) functionality built into the database.
                          Establish and maintain sound backup and recovery policies and procedures.
                          Again, how often yo need to establish policies and procedures?
                          Every time you put in a new app with a different SLA.
                          Backup itself is 100% automated already today.
                          Only if you buy off on the lowest common denominator.
                          Recovery is close to 100%.
                          Oh? Go spend some time in the RMAN forum ...

                          And even if it were close to 100%, 'close' only counts "when playing horseshoes or hand grenades."

                          Most of enterprise backup software support backup and recovery of major RDBMSs.
                          Just specify a date "from" and click Go.
                          A little bit complex with RMAN. You have to type(!) RESTORE DATABASE; RECOVER...
                          Until the cause of failure was something the automation didn't anticipate. Or you then discover that your 100% automated-out-of-the-box backup didn't work the way thought it did. Oh, it 'worked' all right. Just not the way you thought it did.
                          Take care of the Database design and implementation.
                          Where? Only in development shops.
                          Depends on what you mean by 'database design and implementation'. And most companies have some sort of development, even if they don't recognize it or call it that.
                          Implement and maintain database security (create and maintain users and roles, assign privileges).
                          Centralized enterprise security (Domain etc) are in use. Many apps have their security and use basic RDMS security to login App running user.
                          Until such time as "nothing changed" but "I can't connect to my database".
                          Database tuning and performance monitoring.
                          Greatly automated. Ultimately will be 100% automated.
                          Until it's not. See my comment above about developers.
                          Application tuning and performance monitoring.
                          There are enterprise solutions for monitoring. Also Oracle has Grid Control.
                          Application tuning can be done by app vendors.
                          I've NEVER met an app vendor that knew **** about how their app impacted performance. 100% of them throw it back on the DBA. I had an app vendor tell me that Oracle was incapable of sustaining more than five concurrent connections.
                          DBA cannot tune App itself. It may only modify some things in DB that will perform better. And this will be automated.
                          No, because the database cannot anticipate what stupid things the vendor may do. And it can only work with what it is given.
                          Setup and maintain documentation and standards.
                          How often?
                          As often as anything that is documented, changes. As often as it is discovered that something that should be documented, isnt'
                          Plan growth and changes (capacity planning).
                          Well, DBA should do it. But, again, how often?
                          Should be almost constantly. Given budget cycles, you can't wait until your disk is 98% full before asking to buy more.
                          >
                          Work as part of a team and provide 7×24 supports when required.
                          Where such 7×24 support policy exists.
                          Look at my comments above about how these lists get created in the first place.
                          I can tell you from experience that such 24x7 policies are more common than you seem to think. Just about any financial processing business, logistics and transportation business, telecom business ...
                          And what from above should be supported during a night by a human?
                          I see just a restore/recover DB, because a human should make a decision "From which Date".
                          Do general technical trouble shooting and give consultation to development teams.
                          Yes, in Dev shops. Most of shops are not development shops, though may do custom and ad-hoc reporting and small app development. Do they need a dedicated DBA for this? I doubt. Either a developer will be (self)trained to do some DBA's tasks or DBA will become a SQL developer in that team.
                          Interface with MSSQL/MySQL/Oracle for technical support.
                          Oh yeah... :)
                          ITIL Skill set requirement (Problem Management/Incident Management/Chain
                          Sure, two days of training to know basics of ITIL to understand what manager of Helpdesk (Support and Incident Management Team) is talking about.

                          So, I see DBA should go in of 3 directions:
                          1. Very deep technical expert that can help in some rear and difficult cases. How many of them will be needed?
                          2. SQL/ETL/etc Developer. There is not much automation in software development yet.
                          3. DB Design and Architecture. How many of them will be needed? May be more that #1.
                          You seem to think that automation will solve everything. Take that to it's logical conclusion and it will put all of IT out of work. See my comment above regarding "End User Computing'. What you forget is the human element. Not the human DBA trying to do things you think are or soon will be automated. No I'm talking about the humans that create the kinds of problems that automation is *always* trying to catch up with. Pointy Hair Bosses dreaming up new requirements. Bean counters refusing to by an additional 10 gb of disk. Developers that refuse to learn and/or follow best practice. Developers that can't think beyond clicking an icon to create a table. Developers that treat an rdbms as a data dump and try to use Java to re-invent every bit of functionality the db already provides. Systems administrators that delete all of your online redo logs because he needed disk space and 'log files are expendable'. End users that forget their password *EVERY F****** DAY!*

                          No, I don't spend my time managing extent distribution like I had to do with 8i. Yes, a lot of things I had to do manually in 8i are now successfully automated to the point I don't have to do them .. or have simply been engineered out of the system. But no amount of automation will overcome the ways humans (Executives, managers, supervisors, other IT team members, and users) figure out how to bring a system to its knees.

                          This whole discussion reminds me of Dippin' Dots. "The Ice Cream of the Future". Well, it's been "The Ice Cream of the Future" for almost 30 years ....

                          Edited by: EdStevens on Oct 1, 2012 8:55 PM
                          • 10. Re: Are the oracle DBa's seeing an end to their career
                            Osama_Mustafa
                            I don't know why you are thinking in that way , Maybe Database Administration is not like 25 Years ago but no can say i will administer database alone, i am going to tune my database today , oh no you i will install oracle real application cluster
                            Oracle has amazing other tools as database administrator you need to specialized in Something , Tuning , Security , IDM , SSO ,EBS And lot of Other Products But its all about you.

                            If you love what you do , you will not ask yourself question like that , As i told you before maybe there's another databases company that provide database with lower price but it will not be like Oracle , Features you have in Oracle is the most amazing One and its Top of long years of working , High Availability Solution and Backup Recovery Solutions and others .

                            include to this the amazing community that Oracle gaves you here.
                            • 11. Re: Are the oracle DBa's seeing an end to their career
                              Billy~Verreynne
                              user11181920 wrote:

                              So, I see DBA should go in of 3 directions:
                              1. Very deep technical expert that can help in some rear and difficult cases. How many of them will be needed?
                              2. SQL/ETL/etc Developer. There is not much automation in software development yet.
                              3. DB Design and Architecture. How many of them will be needed? May be more that #1.
                              And what happens to The Idiots ™ - do they all get rounded up and send in huge rockets into the sun?

                              If not, who is going to support them in your DBA-is-no-more scenario? Who is going to fix screwup after screwup? Help looking up syntax in a manual? Explain why shareable SQL is important? Show why feature abc needs to be used instead of brainfart +123+ to optimise and scale performance? Or.. well, you should get the picture...

                              You only have to look at the issues and the problems raised right here in this forum, year after year, for the last decade, to see there are a lot of people that
                              a) do not know Oracle
                              b) do not have problem solving skills
                              c) do not know databases
                              d) do not give a damn that they don't know as they believe they do not need to know as there are a few others (like the DBA) that do know

                              And these people are not becoming less. Thanks to the blackbox-database concepts being taught in the fantasy worlds of J2EE and others, these database idiots are becoming more every single year.
                              • 12. Re: Are the oracle DBa's seeing an end to their career
                                Mark Malakanov (user11181920)
                                Ed Stevens
                                Yes, 25 years ago I worked on a machine that was size of a master bedroom and had 256K memory. 10M disk size of a car wheel, and 1" tape recorder for big files.
                                We wrote apps on Fortran and Assembler counting every bit of memory.
                                Today one can have a smartphone with 64G memory, LTE, 10MPx camera, HD camcorder, 3D HDTV, that understands speech, can navigate you through any city fastest way, has realistic games and tons of other applications.
                                Could I even imagine this 30 years ago? No way! But now it is the Reality.
                                And what will be tomorrow?

                                I agree with you that these old CASE tools did not fulfill requirements of total software development automation that time.
                                But this direction is not dead. Many features of them are now in design and development environments.
                                I agree still it is quite far to 100% automated programming. It may sound Sci-Fi.
                                But it is a *direction* where it goes to. It evolves.

                                Regarding imperfectness of (some) App vendors approach to RDBMS.
                                I agree and saw many examples where so powerful RDBMS was underused, used just as bunch of record files,
                                where queries were crafted for one RDBMS and were not ideal for another one.
                                But. SQL as a language is based on a philosophy where low level things are hidden under the hood.
                                User/developer should just specify tables, joins, criteria and output.
                                RDBMS should *automatically* create best way to produce result and produce the result.
                                That is why there are ANSI SQL standards. And ultimately all RDBMSes will work same way for same query.
                                So RDBMS specific should disappear.
                                I agree that the difference, sometimes big difference, still exists *now*.
                                But OP asked about a *Future*.

                                Also RDBMSes are getting more and more forgiving to inefficient designs and programming techniques.
                                As an example, Oracle can dynamically substitute literals with bind vars.

                                Ed Stevens, Billy Verreynne,
                                I agree with many of your points. Many cases you describe I also meet in my professional life.
                                All these results of human mistakes, one-sided or stupid designs, ignorant Java developers etc, etc...
                                And helping to fix of all that is a significant part of my work (and income).

                                But a _Professinal_, when he/she plans his/her career for a significant period of his/her life should not rely on humans stupidity only.
                                Otherwise such professional will like when people make mistakes and idiotic things. I do not think this should be a base of Professional's activity and in a Professional's moral code. (Excuse me for such mentoring.)

                                You can call me a Sci-Fi dreamer, but I believe that software development frameworks will evolve to a degree when a human does not have to model database nor to write queries on non-human language.
                                I believe that many things will be controlled and managed by non-humans in foreseeable future.
                                For example. Today there is a need for car/track drivers. And today Google and mostly all major auto vendors are creating driverless cars.
                                These are already reality. It means in next decade there will not be a need for whole army of professionals - drivers.
                                As soon as these driverless cars will be approved by governments and become cheap enough, Business will replace today's human-machine combos with this cheaper technology. In a mass.
                                Of course some human individuals will be still required - Formula-A pilots, emergency car operators that evacuate failed automated cars, and because salary of track drivers and price of regular trucks will decrease significantly, there will be some old-stile organizations that operate their old-fashion fleets until those machines totally die.
                                Drivers will be still required. But not _all_ drivers, just a small fraction will get these jobs.
                                Whoever is planning for decades to go professional driver career should think twice and consider these things.

                                Similar can be applied to software maintenance people which is DBA.
                                As I said, they will have to go to "Formula-A pilots" like you, Ed Stevens, Billy Verreynne, and Tom Kite, (and many others I did not mentioned, sorry).
                                Others will have to go to other positions where knowledge of RDB is still required - Architects, Designers or SQL/ETL developers - like semi-DBA/semi-developer.
                                But looking on a total head count, will it be there still _same_ demand on traditional DBAs? In this I doubt.

                                Edited by: user11181920 on Oct 2, 2012 12:04 PM - English errors
                                • 13. Re: Are the oracle DBa's seeing an end to their career
                                  jgarry
                                  user11181920 wrote:
                                  Ed Stevens
                                  Yes, 25 years ago I worked on a machine that was size of a master bedroom and had 256K memory. 10M disk size of a car wheel, and 1" tape recorder for big files.
                                  We wrote apps on Fortran and Assembler counting every bit of memory.
                                  Today one can have a smartphone with 64G memory, LTE, 10MPx camera, HD camcorder, 3D HDTV, that understands speech, can navigate you through any city fastest way, has realistic games and tons of other applications.
                                  Could I even imagine this 30 years ago? No way! But now it is the Reality.
                                  And what will be tomorrow?

                                  I agree with you that these old CASE tools did not fulfill requirements of total software development automation that time.
                                  But this direction is not dead. Many features of them are now in design and development environments.
                                  I agree still it is quite far to 100% automated programming. It may sound Sci-Fi.
                                  But it is a *direction* where it goes to. It evolves.
                                  But it also diverges. There has been plenty of web talk about the death of IT departments, supposedly people can just design and build their own apps. I know I've posted on these, pointing out the downsides, and of course they just dismiss me as an old IT dinosaur. But really, the history of this has been one of divergence - once minicomputers became available, some subset of computing migrated to it, some departments could become free of IT (or usually, made their own) and yet IBM still sells mainframes. Once micros became available, anyone could do a spreadsheet, and nowadays that's what they want to use to enter database data. So is there deevolution there? Yes, we all see the problem with lack of data integrity, but users don't, and there is nothing coming to tell them to do it right. And that is just getting worse with users being able to set stuff up in the clouds. Add the facebooks and linkedins of the world making all kinds of stupid user interfaces, and it is getting worse. And of course, IBM sells consolidation to run 32,000 linux instances on a mainframe, or whatever. Now we have Big Data, whatever that is, another New Paradigm to obsolete whatever proper design could actually be in the pipeline.

                                  >
                                  Regarding imperfectness of (some) App vendors approach to RDBMS.
                                  I agree and saw many examples where so powerful RDBMS was underused, used just as bunch of record files,
                                  where queries were crafted for one RDBMS and were not ideal for another one.
                                  But. SQL as a language is based on a philosophy where low level things are hidden under the hood.
                                  User/developer should just specify tables, joins, criteria and output.
                                  RDBMS should *automatically* create best way to produce result and produce the result.
                                  That is why there are ANSI SQL standards. And ultimately all RDBMSes will work same way for same query.
                                  So RDBMS specific should disappear.
                                  I agree that the difference, sometimes big difference, still exists *now*.
                                  But OP asked about a *Future*.
                                  In the future, it will become more clear that the standards only apply for cases where proper relational design is used, and the vast masses are moving away from that. Even the products themselves, and some would argue the standards, are moving away from that, and have been for a long time.

                                  >
                                  Also RDBMSes are getting more and more forgiving to inefficient designs and programming techniques.
                                  As an example, Oracle can dynamically substitute literals with bind vars.
                                  The inefficiency increases much faster than the forgiveness.

                                  >
                                  Ed Stevens, Billy Verreynne,
                                  I agree with many of your points. Many cases you describe I also meet in my professional life.
                                  All these results of human mistakes, one-sided or stupid designs, ignorant Java developers etc, etc...
                                  And helping to fix of all that is a significant part of my work (and income).

                                  But a _Professinal_, when he/she plans his/her career for a significant period of his/her life should not rely on humans stupidity only.
                                  Otherwise such professional will like when people make mistakes and idiotic things. I do not think this should be a base of Professional's activity and in a Professional's moral code. (Excuse me for such mentoring.)
                                  You don't have to like it to rely on it. It's the one thing you can rely on. There is no real conflict with a professional moral code until you have to submit to user requirements beyond your control.

                                  >
                                  You can call me a Sci-Fi dreamer, but I believe that software development frameworks will evolve to a degree when a human does not have to model database nor to write queries on non-human language.
                                  I believe that many things will be controlled and managed by non-humans in foreseeable future.
                                  For example. Today there is a need for car/track drivers. And today Google and mostly all major auto vendors are creating driverless cars.
                                  These are already reality. It means in next decade there will not be a need for whole army of professionals - drivers.
                                  As soon as these driverless cars will be approved by governments and become cheap enough, Business will replace today's human-machine combos with this cheaper technology. In a mass.
                                  Of course some human individuals will be still required - Formula-A pilots, emergency car operators that evacuate failed automated cars, and because salary of track drivers and price of regular trucks will decrease significantly, there will be some old-stile organizations that operate their old-fashion fleets until those machines totally die.
                                  Drivers will be still required. But not _all_ drivers, just a small fraction will get these jobs.
                                  Whoever is planning for decades to go professional driver career should think twice and consider these things.
                                  That kind of infrastructural change will take a long time. People went to the moon in the '60's, yesterday two trucks crashed into trains within 10 miles of each other. There won't be a major shift to driverless in a decade, as good as it would be, it just takes too long to come up with standards and implement them. Standards are the antithesis of competitive free market innovation, yet they are necessary in order to create a proper infrastructure. So what you will see is multiple answers to the driverless car issues, which will have to be hashed out into standards. Then you get all kinds of politics involved. The needs of the many outweigh the needs of the few, but tell that to Congress. Funnily enough, my father-in-law designed an automated transportation system in the '70's for a large company. I doubt if anybody outside of his family has seen it since then, wish I had made a copy when I saw it.

                                  Edit: I meant to add, the California law that was just signed allowing driverless cars still requires someone in the drivers seat. To me, this says the process is equivalent to the early automotive days, when you had to have a flagman walking along in front of the car.

                                  >
                                  Similar can be applied to software maintenance people which is DBA.
                                  As I said, they will have to go to "Formula-A pilots" like you, Ed Stevens, Billy Verreynne, and Tom Kite, (and many others I did not mentioned, sorry).
                                  Others will have to go to other positions where knowledge of RDB is still required - Architects, Designers or SQL/ETL developers - like semi-DBA/semi-developer.
                                  But looking on a total head count, will it be there still _same_ demand on traditional DBAs? In this I doubt.
                                  Looking forward over the next 5-10 years, the head count will be similar or increase, but the traditions will change. A few seconds on google: http://www.bls.gov/ooh/computer-and-information-technology/database-administrators.htm

                                  >
                                  Edited by: user11181920 on Oct 2, 2012 12:04 PM - English errors
                                  Edited by: jgarry on Oct 2, 2012 10:09 AM
                                  • 14. Re: Are the oracle DBa's seeing an end to their career
                                    EdStevens
                                    user11181920 wrote:
                                    Ed Stevens
                                    Yes, 25 years ago I worked on a machine that was size of a master bedroom and had 256K memory. 10M disk size of a car wheel, and 1" tape recorder for big files.
                                    We wrote apps on Fortran and Assembler counting every bit of memory.
                                    Today one can have a smartphone with 64G memory, LTE, 10MPx camera, HD camcorder, 3D HDTV, that understands speech, can navigate you through any city fastest way, has realistic games and tons of other applications.
                                    Could I even imagine this 30 years ago? No way! But now it is the Reality.
                                    And what will be tomorrow?
                                    >
                                    I agree with you that these old CASE tools did not fulfill requirements of total software development automation that time.
                                    But this direction is not dead. Many features of them are now in design and development environments.
                                    I agree still it is quite far to 100% automated programming. It may sound Sci-Fi.
                                    But it is a *direction* where it goes to. It evolves.

                                    Regarding imperfectness of (some) App vendors approach to RDBMS.
                                    I agree and saw many examples where so powerful RDBMS was underused, used just as bunch of record files,
                                    where queries were crafted for one RDBMS and were not ideal for another one.
                                    But. SQL as a language is based on a philosophy where low level things are hidden under the hood.
                                    User/developer should just specify tables, joins, criteria and output.
                                    RDBMS should *automatically* create best way to produce result and produce the result.
                                    That is why there are ANSI SQL standards. And ultimately all RDBMSes will work same way for same query.
                                    So RDBMS specific should disappear.
                                    I agree that the difference, sometimes big difference, still exists *now*.
                                    But OP asked about a *Future*.

                                    Also RDBMSes are getting more and more forgiving to inefficient designs and programming techniques.
                                    As an example, Oracle can dynamically substitute literals with bind vars.

                                    Ed Stevens, Billy Verreynne,
                                    I agree with many of your points. Many cases you describe I also meet in my professional life.
                                    All these results of human mistakes, one-sided or stupid designs, ignorant Java developers etc, etc...
                                    And helping to fix of all that is a significant part of my work (and income).

                                    But a _Professinal_, when he/she plans his/her career for a significant period of his/her life should not rely on humans stupidity only.
                                    Otherwise such professional will like when people make mistakes and idiotic things. I do not think this should be a base of Professional's activity and in a Professional's moral code. (Excuse me for such mentoring.)

                                    You can call me a Sci-Fi dreamer, but I believe that software development frameworks will evolve to a degree when a human does not have to model database nor to write queries on non-human language.
                                    I believe that many things will be controlled and managed by non-humans in foreseeable future.
                                    For example. Today there is a need for car/track drivers. And today Google and mostly all major auto vendors are creating driverless cars.
                                    These are already reality. It means in next decade there will not be a need for whole army of professionals - drivers.
                                    As soon as these driverless cars will be approved by governments and become cheap enough, Business will replace today's human-machine combos with this cheaper technology. In a mass.
                                    Of course some human individuals will be still required - Formula-A pilots, emergency car operators that evacuate failed automated cars, and because salary of track drivers and price of regular trucks will decrease significantly, there will be some old-stile organizations that operate their old-fashion fleets until those machines totally die.
                                    Drivers will be still required. But not _all_ drivers, just a small fraction will get these jobs.
                                    Whoever is planning for decades to go professional driver career should think twice and consider these things.

                                    Similar can be applied to software maintenance people which is DBA.
                                    As I said, they will have to go to "Formula-A pilots" like you, Ed Stevens, Billy Verreynne, and Tom Kite, (and many others I did not mentioned, sorry).
                                    Others will have to go to other positions where knowledge of RDB is still required - Architects, Designers or SQL/ETL developers - like semi-DBA/semi-developer.
                                    But looking on a total head count, will it be there still _same_ demand on traditional DBAs? In this I doubt.

                                    Edited by: user11181920 on Oct 2, 2012 12:04 PM - English errors
                                    Really can't improve on Billy's response, but let me make just a couple of points.

                                    First, the overall message of the above is "technology advances". Sure. Nobody disputes that. But that's a far cry from making a case that the general role of DBA's will become obsolete in the near to mid future.



                                    Second, your statement "But a Professinal, when he/she plans his/her career for a significant period of his/her life should not rely on humans stupidity only." It's not a matter of "professionalism" or "moral code" (and I must say I'm a bit put off by the implications of such phrases in this context) but a matter of recognizing historical reality. It (stupidty and its first cousins, Folly and Hubris) seems to always win out, and it occurs at all levels of human endeavor. From the guy who ruined a perfectly good car because he was too stupid to believe that changing the oil mattered, to the king that lost an empire because he was too stupid to take seriously the concerns of the colonists. H.L. Menken is quoted as saying "Nobody ever went broke underestimating the taste of the American public." I'd modify that to say ""Nobody ever went broke underestimating the depths of human folly."

                                    As to driver-less cars as an example of anything. Yes the technology exists for a demo project. Maybe even a fairly large scale demo project. But full blown, mass deployment? Heck, the technology to lower a gate at a railroad crossing is not 100% reliable. Have you ever had the electricity go out at your house? And that is really my point, coming back to the original question. Technology can do marvelous things, but all technology has failure points. And the more critical the application of the technology, the more critical it will be to have knowledgeable humans to try to maintain the technology and be able to step in when (not if) it fails.
                                    1 2 3 4 Previous Next