4 ms·

I think that a key explanation of Oracle success is that the complexity of their database administration has created a generation of full time jobs: DBA. These

by webreac 10y ago

I think that a key explanation of Oracle success is that the complexity of their database administration has created a generation of full time jobs: DBA. These people are like salesman working for Oracle to defend the future of their job. They are well paid, but this cost nothing to Oracle. At the opposite, Oracle can sell training.

toyg 10y ago
Most of these jobs are offshored now, so it's not as relevant a factor as you think. What is relevant is the amount of business applications and solutions built on the database, that took years to develop and would cost a fortune to replace.
- z3t4 10y ago
  is it not standard practice to support at least two different db systems !?
  - toyg 10y ago
    For certain values of "support". Say you start on Oracle and then want to move to SqlServer? Migration will likely be a risky endeavor, even if the application supports either db when starting from scratch. To begin with, you'll need something to copy schemas across, be it in the app itself or not, and hope everything made it across. Then you'll have to hope the app doesn't need db-specific stuff (say, a sequence that you only get on sqlserver) that you don't have because you started on Ora. And then you'll have to move all the 3rd party tooling and hacks that you built over the years around that same database - from backup solutions to custom queries etc. It's rarely as easy as "copy it all and turn it back on", and all this work often has to be done by expensive application specialists. At that point, having to choose between paying hundreds of thousands to move db, or a few extra thousands per year to keep things as they are, the business decision is not as simple as one would think.
- sqldba 10y ago
  DBA jobs haven't been entirely offshore'd. It happens in cycles. * Offshore to save money. Databases are a car, just follow the script / maintenance manual and everything will be okay right? * Discover the awful quality, security, never-ending cycle of bodies, lack of retention of information, zero innovation, frustrated staff having to try to deal with them, and and most of all costs which creep up (a lot like Oracle licensing). * Insource to qualified internal staff and retain knowledge, save money, and fix all the problems the outsourced company wouldn't. * Now that everything is fixed, create work manuals, and offshore again. This will get out of date over time, servers will get replaced, new software comes along, and things go to pot again. Repeat. To be fair, companies also often institute long and complex policies which stifle any kind of remediation an offshore staffer would do - because they can't. Internal employees learn the system, how to get things done, and they do it. I work for a team that has taken over from multiple offshore companies in this way. We find all of these things and worse, really just the most awfully maintained systems around - no backups, no maintenance, no organisation, nothing. They don't even patch but they say they do! And they've paid millions (and tens of millions) for the privilege! There's really no comparison so don't mistake the two for a second. As for automation - well - tools have made it so that one DBA can "manage" hundreds of servers at once if they're standardised in certain ways. But you'd be surprised at how many things can go wrong and how few can be automated, especially when the rest of the companies don't have proper automation infrastructure in place. Large enterprises are still fiefdoms of managers who want local employees and to retain their own jobs. Performance tuning and improvements though are extremely time consuming. You can, for some projects, focus entirely on single digit servers for years at a time if they're important enough.
pjmlp 10y ago
That is relevant job for any RDMS, not only Oracle.
jimnotgym 10y ago
Please could they all retrain for Postgres!
- mr_overalls 10y ago
  Oracle DBA here. Oracle Database 10g through 12c have provided me with a steady income for 6+ years, but enough is enough. It's a solid, powerful product, but Oracle's behavior over the years has been so ridiculous, so abusive, so damaging to open source. . . I've had enough. Am doing exactly what you suggest. All of my personal projects now run Postgres.
  - asah 10y ago
    Importantly, there's finally enough high-paying work in Postgres to support DBAs like yourself.
rodgerd 10y ago
The Exa* pitch complicates that, though. I've dealt with Oracle DBAs who were rabid to get their hands on Exa* units so they could "get rid of the sysadmins." They cooled their jets when they heard a big part of the Exa* pitch is reducing reliance on DBAs, as well. Oracle's in an awkward place. They want to get to the new world of cloud and appliance without burning down the old world, while preserving their profitability, and that's quite hard.

by webreac 10y ago

toyg 10y ago

Most of these jobs are offshored now, so it's not as relevant a factor as you think. What is relevant is the amount of business applications and solutions built on the database, that took years to develop and would cost a fortune to replace.

z3t4 10y ago
is it not standard practice to support at least two different db systems !?
- toyg 10y ago
  For certain values of "support". Say you start on Oracle and then want to move to SqlServer? Migration will likely be a risky endeavor, even if the application supports either db when starting from scratch. To begin with, you'll need something to copy schemas across, be it in the app itself or not, and hope everything made it across. Then you'll have to hope the app doesn't need db-specific stuff (say, a sequence that you only get on sqlserver) that you don't have because you started on Ora. And then you'll have to move all the 3rd party tooling and hacks that you built over the years around that same database - from backup solutions to custom queries etc. It's rarely as easy as "copy it all and turn it back on", and all this work often has to be done by expensive application specialists. At that point, having to choose between paying hundreds of thousands to move db, or a few extra thousands per year to keep things as they are, the business decision is not as simple as one would think.
sqldba 10y ago
DBA jobs haven't been entirely offshore'd. It happens in cycles. * Offshore to save money. Databases are a car, just follow the script / maintenance manual and everything will be okay right? * Discover the awful quality, security, never-ending cycle of bodies, lack of retention of information, zero innovation, frustrated staff having to try to deal with them, and and most of all costs which creep up (a lot like Oracle licensing). * Insource to qualified internal staff and retain knowledge, save money, and fix all the problems the outsourced company wouldn't. * Now that everything is fixed, create work manuals, and offshore again. This will get out of date over time, servers will get replaced, new software comes along, and things go to pot again. Repeat. To be fair, companies also often institute long and complex policies which stifle any kind of remediation an offshore staffer would do - because they can't. Internal employees learn the system, how to get things done, and they do it. I work for a team that has taken over from multiple offshore companies in this way. We find all of these things and worse, really just the most awfully maintained systems around - no backups, no maintenance, no organisation, nothing. They don't even patch but they say they do! And they've paid millions (and tens of millions) for the privilege! There's really no comparison so don't mistake the two for a second. As for automation - well - tools have made it so that one DBA can "manage" hundreds of servers at once if they're standardised in certain ways. But you'd be surprised at how many things can go wrong and how few can be automated, especially when the rest of the companies don't have proper automation infrastructure in place. Large enterprises are still fiefdoms of managers who want local employees and to retain their own jobs. Performance tuning and improvements though are extremely time consuming. You can, for some projects, focus entirely on single digit servers for years at a time if they're important enough.

pjmlp 10y ago

That is relevant job for any RDMS, not only Oracle.

jimnotgym 10y ago

Please could they all retrain for Postgres!

mr_overalls 10y ago
Oracle DBA here. Oracle Database 10g through 12c have provided me with a steady income for 6+ years, but enough is enough. It's a solid, powerful product, but Oracle's behavior over the years has been so ridiculous, so abusive, so damaging to open source. . . I've had enough. Am doing exactly what you suggest. All of my personal projects now run Postgres.
- asah 10y ago
  Importantly, there's finally enough high-paying work in Postgres to support DBAs like yourself.

rodgerd 10y ago

The Exa* pitch complicates that, though. I've dealt with Oracle DBAs who were rabid to get their hands on Exa* units so they could "get rid of the sysadmins." They cooled their jets when they heard a big part of the Exa* pitch is reducing reliance on DBAs, as well. Oracle's in an awkward place. They want to get to the new world of cloud and appliance without burning down the old world, while preserving their profitability, and that's quite hard.