Hi! I'm your Oracle DBA.



  • <font face="Verdana"><font size="2">I love the irony that I choose a username (Your Oracle DBA) because I am an Oracle DBA, and then
    I find this forum. I can't wait to dig in! Be aware that while I pay my
    mortgage working with Oracle, all day, every day, I am not a fanboy.



    About me: I work for a Fortune 100 company, I work with heavy duty
    stuff. I don't do blog installs and little bitty web sites. I architect
    and build large-scale enterprise databases and the hardware that goes
    along with it. Nothing I touch runs on hardware that costs less than
    $500K. The software and support licenses can add 50% to that cost. Some of my systems run on $7 mil+ in server hardware + SAN. My development and test lab environments are far more powerful than most production systems. I
    have systems that can churn 500-1000 transactions per second, 24x7x365 and
    never miss a beat. Which is good, because when some of them are down, my company can lose tens of thousands of dollars per minute. I have 10 years of experience working with Oracle.
    I'm a talented engineer, and I know what I'm doing.



    That being said...



    Before I get to the RAC issues, let's talk about Oracle in general.



    Rule #1: You cannot install and run Oracle yourself.




    You can play with it, but you can't run business critical applications
    with Oracle if you have no experience. Period. It's suicidal. There are
    so many things that can go wrong, so many design and architecture
    decisions which you will probably make very casually and be boxed into
    a corner with later, and so many things you will be unable to fix if
    they break, that it's just insane to try. Which brings me to my next
    point...



    Rule #2: You probably don't need Oracle.




    I do Oracle for a living, and I'll be the first to tell you that you
    probably do not need Oracle. I would say 95% of business app
    installations that currently run Oracle would be just fine with MySQL.
    I personally use MySQL and it's great for what it is -- simple, quick,
    and dirty. That's what most of us need. I'll never understand why so
    many business solutions spec out Oracle when something much lighter
    will do. Sure, I'll let them continue to pay me to do the work, but when I
    build a solution that I know won't utilize even 2% of Oracle's
    scalability and features, I feel bad. I really do.



    Rule #3: If you need Oracle, you'll know.



    I think this doesn't need much explanation. If you have a good handle
    on your needs, you'll know if you need Oracle. If you think maybe you need Oracle, you probably don't. If you're not sure, you
    may need to get a better understanding of your requirements before you
    start building, but you'll probably find that you don't need Oracle.
    Amazon needs Oracle. eBay needs Oracle. Major telecoms need Oracle. The
    big accounting firms need Oracle. World of Warcraft needs Oracle. Banks
    need Oracle. You and your business probably do not need Oracle.



    Oracle RAC



    Oracle RAC can be a royal pain in the ass. Period. It's incredibly
    complex, and it's also incredibly difficult to get working properly.
    I've worked with Oracle, UNIX, Linux, C, Perl, etc for 10 years, and
    there is absolutely nothing I've encountered that is more difficult to
    get set up and running properly than an Oracle RAC. The good news? You
    probably don't need it. Will I sugarcoat the installation issues?
    Absolutely not. It's very complex. It has intimate interactions with
    the very lowest level system stuff, like memory segments and
    semaphores. It has very intimate interactions with your storage, which
    may be layered with Sun Cluster, or Veritas, or something else. You
    pretty much have to be an advanced UNIX admin to even think about doing
    a production install. And when it all goes wrong, lordy does it go
    wrong. It goes horribly wrong. I made the mistake of letting Oracle
    professional services and Sun professional services build my new
    production cluster for me. That was two months ago. It's completely
    trashed. They can't make it run right. I'm going in next week to do it
    myself. So is it complex? Yeah. Is it overly complex? Probably. But, it
    offers some great advantages in terms of features and scalability.



    I have RAC systems with 20+ months of uptime with no outages. Zero.
    Nada. That includes OS and database patching, because we can take a
    node offline, patch it, bring it back up, swing all the resources over
    to the patched node, then patch all the other nodes. When it's well set
    up, and you have very competent people managing it, it's a wonderful
    thing. All other times, it pretty much sucks.



    That's it for now. Bring on the hate! </font></font>



  • One can only hope that you're really that good. I've seen too many "Oracle Specialists" in my career that were just mouthing off and were responsible for oversized and inferior solutions based on the said product.

    MySQL? Yes, it has its purpose - if you don't need views, triggers, stored procedures/packages, referential integrity, online backup capability, etc. Yes, I know, there are different "table types" - with different limitations. If you don't want Oracle (even the XE version) but still a database that serves its name, take a look at postgres, OpenIngres, MaxDB (also renamed to mysql?), even firebird would do for smaller applications.

    l.

     



  • @lofwyr said:

    One can only hope that you're really that good. I've seen too many "Oracle Specialists" in my career that were just mouthing off and were responsible for oversized and inferior solutions based on the said product.

    MySQL? Yes, it has its purpose - if you don't need views, triggers, stored procedures/packages, referential integrity, online backup capability, etc. Yes, I know, there are different "table types" - with different limitations. If you don't want Oracle (even the XE version) but still a database that serves its name, take a look at postgres, OpenIngres, MaxDB (also renamed to mysql?), even firebird would do for smaller applications.

    l.

     

    MySQL does Views, Triggers, and Stored Procedures. When using InnoDB (which you should be) it also supports referential integrity and online backup capability.

    Please do research before making broad claims.



  • @Your Oracle DBA said:

    <FONT face=Verdana><FONT size=2>I love the irony that I choose a username (Your Oracle DBA) because I am an Oracle DBA, and then I find this forum. I can't wait to dig in! Be aware that while I pay my mortgage working with Oracle, all day, every day, I am not a fanboy.
    </FONT></FONT>

    If you are working with Oracle all day every day, you cannot be a fanboy. Not if you are sane anyway.

    I just took a short term Oracle warehouse upgrade to remind we of why I don't do Oracle. It didn't take long at all.




  • <font face="Verdana"><font size="2">I have systems that can churn 500-1000 transactions per second, 24x7x365 and never miss a beat.


    Hmmm... You're this wonderful, and don't realize that 24x7x365 is wrong?

    It's either 24x7 or 24x365 - it can't be both. (Unless, of course, you mean that the transactions only churn for 61320 hours and then die.)
    </font></font>


  • @KenW said:


    <FONT face=Verdana><FONT size=2>I have systems that can churn 500-1000 transactions per second, 24x7x365 and never miss a beat.


    Hmmm... You're this wonderful, and don't realize that 24x7x365 is wrong?

    It's either 24x7 or 24x365 - it can't be both. (Unless, of course, you mean that the transactions only churn for 61320 hours and then die.)
    </FONT></FONT>

    Wow, aren't you clever... 

    Couldn't you find any grammer or spelling mistakes to be a pedantic nit about? 

    (and I'm pretty sure that the comma in your first sentence is inproperly placed)



  • Sounds nice - superfast servers with test environments.
    We have superslow servers with nowhere to test and no time to anyway.
    We organize downtime at the weekend, do a backup of the dbs and oracle install, try the patch, see if it worked with as many apps as possible and then rollback or commit.
    Is this anyone else's reality?



  • are you my co-worker?



  • inproperly...that's a word now, is it?



  • @wiggzie said:

    inproperly...that's a word now, is it?

    In future please phrase such questions "Is inproperly now a word?"

    Bad grammer is a something up with which I shall not put.



  • @KenW said:


    <FONT face=Verdana><FONT size=2>I have systems that can churn 500-1000 transactions per second, 24x7x365 and never miss a beat.


    Hmmm... You're this wonderful, and don't realize that 24x7x365 is wrong?

    It's either 24x7 or 24x365 - it can't be both. (Unless, of course, you mean that the transactions only churn for 61320 hours and then die.)
    </FONT></FONT>

    Clearly he means "24 hours a day, 7 days a week, 365 weeks a heptayear".



  • eh...I think you'll find it is perfectly acceptable grammar, idiot.




  • MySQL does Views, Triggers, and Stored Procedures.


    Ah, the blessings of version 5. However, there's still a lot to be desired, if you were using Oracle for example.

    Views: no subqueries.
    Trigger: like functions, no SELECT statements.
    Stored Procedures: just a few limitations: http://mysql.com/doc/refman/5.0/en/routine-restrictions.html


    When using InnoDB (which you should be) it also supports referential integrity and online backup capability.


    Unfortunately there are a couple of other table types that offer certain advantages/disadvantages and they are beeing used, such as ISAM for example.


    Please do research before making broad claims.




    I should have been more specific on this topic. How about you doing some research too?

    l.



  • @Some Idiot said:

    If you are working with Oracle all day every day, you cannot be a fanboy. Not if you are sane anyway.

    Working as a developer or admin? Sounds like the rant of someone who's not up to task ...

    @Some Idiot said:

    I just took a short term Oracle warehouse upgrade to remind we of why I don't do Oracle. It didn't take long at all.

    Usually another rant from people lacking user guide reading skills ....

    l.

     



  • So..... I work for Alcoa... enough said about my job. anyway, do you have any thoughts on our use of Oracle. We use the RAC system for our Production along with about 30 other instances of the application that run off numerous other UNIX servers. I HATE supporting this. It works godd except for the time that it doesn't (which means in my eyes.... something is always going wrong)... the application itself doesn't always function right, but we are daily opening more and more SR's to have work done and patches created to make it work "better".... I just typed I hate Oracle into Google and this was the first site that came up, so I thought I'd drop in



  • Question is: what application are you using? Also written by Oracle? In-house development? If the problem is in the application, then why blame the database?

     

    l.



  • @Floppydisk said:

    Sounds nice - superfast servers with test environments.
    We have superslow servers with nowhere to test and no time to anyway.
    We organize downtime at the weekend, do a backup of the dbs and oracle install, try the patch, see if it worked with as many apps as possible and then rollback or commit.
    Is this anyone else's reality?

    <font face="Verdana" size="2">This is most people's reality. We do the best with what we have. Generally you won't get everything you need to do a proper job until something catastrophic happens. Once you explain how it could have been prevented with proper QA and testing, management tends to get the picture quickly and somehow magically finds the funding to do all the things that they wouldn't do before.

    My environment is nice, but it's only happened in the last year or so, and only after I spent a whole lot of time explaining how poor our testing and release management was. Of course no one listened (they never do) but after a month of trying to deploy a new app for testing in a fresh new production environment, management finally got the message that working fast and not understanding the interactions between all the disparate pieces of our apps was a real stumbling block.

    You know how it goes -- your development team just hacks and hacks and hacks away until it works, and they leave a swath of destruction in their path. Unused code everywhere, database object that are no longer used sitting there gathering dust, no understanding of which pieces of the database their code talks to... Then it's time to deploy this mess somewhere else, and no one knows how to do it. This is when they come by my desk and ask for help. I'm always happy to do it, but it is annoying.

    When I started as a DBA, I was told by a senior team member that a DBAs job is mostly to just say "no". I'm not in total disagreement with that statement. A DBA says no way more than he says yes. It's hard to be the gatekeeper in a fast-paced environment. So I have my stuff set up so that I can say "yes" a whole lot. The DBA who works for or within a development group has to walk a fine line -- he must keep everything organized and clean and well-documented, but also must to be able to answer development requests as quickly as possible. And do it all with a smile. If you're a development DBA and want to keep your job for any length of time, you'd better be talented, and you'd better have a good relationship with your development team. I hear far too many horror stories from my developer friends about how they HATE their DBA. I never understood this type of DBA myself. I'm a part of the team and I live and die by our products just like the rest of the team.

    As for difficult deployments and upgrades -- yeah, that's pretty much how it goes for most people. Even if you test thoroughly, it doesn't always work out exactly how you planned. That's when you hope you have a talented team that can work through the issues in real time and not have to roll back a deployment or upgrade just because something unforeseen occurrs. Engineers who have to follow a script and freak out if anything bad happens... Yeah, they're not even engineers. They're computer operators, and they're useless. That's why when the heavy stuff happens, I like to be there working the issues. I can troubleshoot almost any type of database issue that may occur. There are some that would stump me, I'm sure, but most things are fixable if you know how to analyze, diagnose, test, and fix. This is the single most important skill set an engineer can have. Anyone can follow the instructions. Someone who can make the thing work when something bad happens... That's they person you want on your team.
    </font>



  • @lofwyr said:

    @Some Idiot said:

    If you are working with Oracle all day every day, you cannot be a fanboy. Not if you are sane anyway.

    Working as a developer or admin? Sounds like the rant of someone who's not up to task ...

    @Some Idiot said:

    I just took a short term Oracle warehouse upgrade to remind we of why I don't do Oracle. It didn't take long at all.

    Usually another rant from people lacking user guide reading skills ....

    l.

     

    Thanks for your insight. Very insightful.

    Was your assesment of my user guide reading prowess based on anything I posted, or were you just being a rude sh*t to push some agenda of yours? I'm sorry if you feel my dislike of working with databases, and Oracle in particular, is some kind of personal attack on you to point that you have to retalliate with personal attack against me. Very sorry. Very very sorry.



  • @Some Idiot said:


    Thanks for your insight. Very insightful.

    You're welcome.

    @Some Idiot said:


    Was your assesment of my user guide reading prowess based on anything I posted, or were you just being a rude sht to push some agenda of yours? I'm sorry if you feel my dislike of working with databases, and Oracle in particular, is some kind of personal attack on you to point that you have to retalliate with personal attack against me. Very sorry. Very very sorry.


    People who state that others can't be sane if they prefer to work day to day with a certain product whithout any argument usually do lack the mentioned skills. I could be wrong of course, but your last answer again indicates that you belong to the group of people that bullsh
    t their way through IT. So yes, you should be very sorry, very very sorry.

    l.



  • @lofwyr said:

    People who state that others can't be sane if they prefer to work day to day with a certain product whithout any argument usually do lack the mentioned skills. I could be wrong of course, but your last answer again indicates that you belong to the group of people that bullsh*t their way through IT. So yes, you should be very sorry, very very sorry.

    l.

    I like to think I am from a group of people in IT who are familiar enough with a few technologies that they can have a light hearted dig at a particular technology without having one of those religious attitudes about it. Y'know, that banter thing. What's this forum called again?

    I have found that people who appear personally offended by any negative comment about a particular technology are more interested in politics than tech. It's really gets old. I may be wrong about you, but you seem to jump to conclusions and agressively push those conclusions. I guess you normally appear 'right' to the pointy haired boss first, for what it's worth.

    I am sorry if I offended you. In fact I take it all back. Oracle is fantastic. People who use Oracle are wonderful. I love Oracle because it aint Paradox. Really..... <FONT size=1>Zzzzzzzzzzzzzzzzzz</FONT>



  • @Your Oracle DBA said:


    <font face="Verdana" size="2">This is most people's reality. We do the best with what we have. Generally you won't get everything you need to do a proper job until something catastrophic happens. Once you explain how it could have been prevented with proper QA and testing, management tends to get the picture quickly and somehow magically finds the funding to do all the things that they wouldn't do before.
    </font>


    you must not have been reading on this site for very long.



  • @Some Idiot said:

    I like to think I am from a group of people in IT who are familiar enough with a few technologies that they can have a light hearted dig at a particular technology without having one of those religious attitudes about it. Y'know, that banter thing. What's this forum called again?

    If that leads to such blunt statements, I'd say: think again. Yes, I know this forum is called the Oracle Hate Club. Funny thing about is: most statements in this part of thedailywtf show the inadeqacies of the posterst, not the product, which could have been solved by reading the user guide. Which doesn't mean that said product doesn't have it's irks.

    @Some Idiot said:

    I have found that people who appear personally offended by any negative comment about a particular technology are more interested in politics than tech. It's really gets old. I may be wrong about you, but you seem to jump to conclusions and agressively push those conclusions. I guess you normally appear 'right' to the pointy haired boss first, for what it's worth.

    Yes, your complaint that I was riding a personal attack against you gets old very fast. I don't deal in religions, I deal in IT. I can't persuade a product to do the things I want through rants or prayers, I'll have to use user guides, knowledge and (sometimes) support. It really works ... The one that's showing off the PHB attitude is you by giving unfounded claims, maybe it's time for you to take a look in the mirror.

    @Some Idiot said:

    I am sorry if I offended you. In fact I take it all back. Oracle is fantastic. People who use Oracle are wonderful. I love Oracle because it aint Paradox. Really..... <FONT size=1>Zzzzzzzzzzzzzzzzzz</FONT>

    I really don't care if you're comments were intended to offend me. All they did show me was someone who likes to offer mediocre advice from a lack of knowledge for a certain background. Congratulations, you're a member of the majority working (and bullsh*tting) their way through their business career. Me? I like to keep it with user guides and experience ...

    l.

     



  • @Your Oracle DBA said:

    <font face="Verdana"><font size="2">I love the irony that I choose a username (Your Oracle DBA) because I am an Oracle DBA, and then
    I find this forum. I can't wait to dig in! Be aware that while I pay my
    mortgage working with Oracle, all day, every day, I am not a fanboy.



    About me: I work for a Fortune 100 company, I work with heavy duty
    stuff. I don't do blog installs and little bitty web sites. I architect
    and build large-scale enterprise databases and the hardware that goes
    along with it. Nothing I touch runs on hardware that costs less than
    $500K. The software and support licenses can add 50% to that cost. Some of my systems run on $7 mil+ in server hardware + SAN. My development and test lab environments are far more powerful than most production systems. I
    have systems that can churn 500-1000 transactions per second, 24x7x365 and
    never miss a beat. Which is good, because when some of them are down, my company can lose tens of thousands of dollars per minute. I have 10 years of experience working with Oracle.
    I'm a talented engineer, and I know what I'm doing.



    That being said...



    Before I get to the RAC issues, let's talk about Oracle in general.



    Rule #1: You cannot install and run Oracle yourself.




    You can play with it, but you can't run business critical applications
    with Oracle if you have no experience. Period. It's suicidal. There are
    so many things that can go wrong, so many design and architecture
    decisions which you will probably make very casually and be boxed into
    a corner with later, and so many things you will be unable to fix if
    they break, that it's just insane to try. Which brings me to my next
    point...



    Rule #2: You probably don't need Oracle.




    I do Oracle for a living, and I'll be the first to tell you that you
    probably do not need Oracle. I would say 95% of business app
    installations that currently run Oracle would be just fine with MySQL.
    I personally use MySQL and it's great for what it is -- simple, quick,
    and dirty. That's what most of us need. I'll never understand why so
    many business solutions spec out Oracle when something much lighter
    will do. Sure, I'll let them continue to pay me to do the work, but when I
    build a solution that I know won't utilize even 2% of Oracle's
    scalability and features, I feel bad. I really do.



    Rule #3: If you need Oracle, you'll know.



    I think this doesn't need much explanation. If you have a good handle
    on your needs, you'll know if you need Oracle. If you think maybe you need Oracle, you probably don't. If you're not sure, you
    may need to get a better understanding of your requirements before you
    start building, but you'll probably find that you don't need Oracle.
    Amazon needs Oracle. eBay needs Oracle. Major telecoms need Oracle. The
    big accounting firms need Oracle. World of Warcraft needs Oracle. Banks
    need Oracle. You and your business probably do not need Oracle.



    Oracle RAC



    Oracle RAC can be a royal pain in the ass. Period. It's incredibly
    complex, and it's also incredibly difficult to get working properly.
    I've worked with Oracle, UNIX, Linux, C, Perl, etc for 10 years, and
    there is absolutely nothing I've encountered that is more difficult to
    get set up and running properly than an Oracle RAC. The good news? You
    probably don't need it. Will I sugarcoat the installation issues?
    Absolutely not. It's very complex. It has intimate interactions with
    the very lowest level system stuff, like memory segments and
    semaphores. It has very intimate interactions with your storage, which
    may be layered with Sun Cluster, or Veritas, or something else. You
    pretty much have to be an advanced UNIX admin to even think about doing
    a production install. And when it all goes wrong, lordy does it go
    wrong. It goes horribly wrong. I made the mistake of letting Oracle
    professional services and Sun professional services build my new
    production cluster for me. That was two months ago. It's completely
    trashed. They can't make it run right. I'm going in next week to do it
    myself. So is it complex? Yeah. Is it overly complex? Probably. But, it
    offers some great advantages in terms of features and scalability.



    I have RAC systems with 20+ months of uptime with no outages. Zero.
    Nada. That includes OS and database patching, because we can take a
    node offline, patch it, bring it back up, swing all the resources over
    to the patched node, then patch all the other nodes. When it's well set
    up, and you have very competent people managing it, it's a wonderful
    thing. All other times, it pretty much sucks.



    That's it for now. Bring on the hate! </font></font>


    Your message totally clarifies to me what a great product Oracle is... An overpriced, unusable, unstable piece of junk that requires a warehouse of expensive hardware, an army of expensive and arrogant administrators, and a great deal of masochism.

    Databases are just a hack for the ancient problem of 'not enough memory'.  It is good luck for those with careers in table and row hacking and other administration of these dinosaurs that they also became useful for stuff like SQL and relation-based theory of information storage and retrieval, so they will always have some sort of life in the outskirts of real Computer Science people.  But in truth, as larger and larger high speed random access solid state type memory becomes available, we will eventually have huge systems built with in-memory objects instead of the outdated tables, rows and columns that Oracle administrators seem to think are the final solution to every computing problem.

    That being said, and in addition to what I have said, I consider most Oracle DBAs to be complete hacks.  Honestly, if they were really that talented, they would go work for Oracle itself and actually be the ones to design and implement the big bad clusterable scalable databases, instead of being a lowly administrator of someone else's product.  Saying you are some big bad awesome Oracle DBA is tantamount to someone claiming to to be a big bad awesome Microsoft Word administrator... it will make all the real engineering people who designed and programmed Word truly laugh their asses off, just like the real database engineers are the ones who design and program the databases.

    LOL flame away!  Feel the HATE!



  • @CodeRage said:

    Databases are just a hack for the ancient problem of 'not enough memory'.  It is good luck for those with careers in table and row hacking and other administration of these dinosaurs that they also became useful for stuff like SQL and relation-based theory of information storage and retrieval, so they will always have some sort of life in the outskirts of real Computer Science people.  But in truth, as larger and larger high speed random access solid state type memory becomes available, we will eventually have huge systems built with in-memory objects instead of the outdated tables, rows and columns that Oracle administrators seem to think are the final solution to every computing problem.

    Interesting ... will this revolution come before or after the working AIs that will take away the ancient problem of  'not written code'? Or were you just playing buzzword bingo again?

    l.



  • he's to stupid to realize that the need to store data will grow equally fast as the ability to store data.



  • @wiggzie said:

    eh...I think you'll find it is perfectly acceptable grammar, idiot.


    Please enable sarcasm detectors before posting on daily wtf forums...



  • @tster said:

    he's to stupid to realize that the need to store data will grow equally fast as the ability to store data.

    I'm not so sure, with your compression algorithm and all!  ("too" compressed to "to")..  Sorry, I don't like to pick on typos, but thought it funny.

    I am trying to figure out what your point is though.  Are you saying my belief (that large arrays of solid state memory will replace hard drives) fails to account for the possibility that such arrays will not be large enough to handle the need to store increasing amounts of data?  On the contrary, I am confident such breakthroughs will be REQUIRED to keep up with that need.  It wasn't too long ago that the "BIG DATA" was put on tape, because the hard drives were not large enough to store it.  Even virtual memory implemented with a hard drive isn't as much of a need anymore due to the ever-increasing amounts of RAM available at a reasonable cost.

    My point is that when breakthroughs occur in high speed, randomly addressable memory, spinning platters to store data will eventually go the way of the reel-to-reel tape drive.  Consider that a 4 gigabyte SD card that fits on your thumb is affordable right now.

    Don't get me wrong, databases will continue to exist in some form.  But the mode of storage will not be rows, tables and indexes spanned across many disk platters.  Most of the complexities of setting up huge databases come from managing this type of storage, and optimizing this type of storage for fast retrieval.  With breakthroughs in storage technology, the way we use and store data will change dramatically, and the uber-DBA will become as rare as a Tape Operator in a Data Center.



  • @CodeRage said:

    @tster said:
    he's to stupid to realize that the need to store data will grow equally fast as the ability to store data.

    I'm not so sure, with your compression algorithm and all!  ("too" compressed to "to")..  Sorry, I don't like to pick on typos, but thought it funny.

    I am trying to figure out what your point is though.  Are you saying my belief (that large arrays of solid state memory will replace hard drives) fails to account for the possibility that such arrays will not be large enough to handle the need to store increasing amounts of data?  On the contrary, I am confident such breakthroughs will be REQUIRED to keep up with that need.  It wasn't too long ago that the "BIG DATA" was put on tape, because the hard drives were not large enough to store it.  Even virtual memory implemented with a hard drive isn't as much of a need anymore due to the ever-increasing amounts of RAM available at a reasonable cost.

    My point is that when breakthroughs occur in high speed, randomly addressable memory, spinning platters to store data will eventually go the way of the reel-to-reel tape drive.  Consider that a 4 gigabyte SD card that fits on your thumb is affordable right now.

    Don't get me wrong, databases will continue to exist in some form.  But the mode of storage will not be rows, tables and indexes spanned across many disk platters.  Most of the complexities of setting up huge databases come from managing this type of storage, and optimizing this type of storage for fast retrieval.  With breakthroughs in storage technology, the way we use and store data will change dramatically, and the uber-DBA will become as rare as a Tape Operator in a Data Center.

    Ok... first of all your premise is completely wrong.  Databases were not invented to solve the problem of 'no room for data' in fact a database is somewhere between a plain text ini file and a xml file in data storage efficiency.  Nobody invested in a database to solve the problem of trying to find space to store Aunt Mabel's phone number.  Databases answer the age old question of where the h-e-double hockey sticks did I put Aunt Mabel's phone number in amongst my Tera-bytes of porn.  Later on as they became more advanced they also started to answer the question of what happens if that darn hacker changes Aunt Mabel's phone number while I'm looking at it, what do I see.  And if I download too much porn and my computer blows up will is the data stored somewhere else too and I can still get her number without having worry about one crashed server. 

    So given that, database technology become more and more important as data storage becomes large and quicker... you have more stuff and thus it becomes more and more difficult to find a particular bit of that stuff in the huge mess.  Currently only google seems to have anything that even competes with relational databases as a way of finding that one piece of data your looking for in a very large store.  And even there it is probably not better in terms of speed of lookup only in terms of easy of use.  Databases are most useful when data retrieval is as close to random access as possible, and your right a lot of effort in the current databases is spent trying to hide the fact that data retrieval on disks is not perfectly random access.  It would be truely painful to try and get data off of tapes via a database... but surely better than trying to do a search for a specific string in a file in a file system distributed across multiple tapes using Windows Find.

    Now if you want to argue that current databases have shown that you can get very good preformance out of a small, cheap, easy to install, easy to manage package rather than Oracle's nightmare of complexity then I can start to agree with you.  The Uber-DBA is generally not required these days if businesses would buy the database that was right for them and not immediately jump into Oracle and all its headaches just cause 'everyone knows its the best.'  I think that was one of the main points that the original poster was trying to get across.  He can deal with Oracle, he does deal with Oracle and he is pretty darn sure that most of the installations he's run into do not need it and that the owners in question would have been better served with another solution.



  • Don't forget ACID. These are universal requirements of a database, unrelated to the relational model or using hard disks for storage. The mentioned "larger high speed random access solid state type memory" would have to provide that just as well.



  • @Your Oracle DBA said:

    <font face="Verdana"><font size="2">

    Rule #1: You cannot install and run Oracle yourself.

    Rule #2: You probably don't need Oracle.

    Rule #3: If you need Oracle, you'll know.

    </font></font>


    The "real WTF" here is that this guy really, really, knows what he's talking about and most posters are not listening. Why is that?
    • Because Your Oracle DBA is saying Oracle is not for amateurs?
    • Or because they think they know everything already, ergo what they don't know must suck?
    Random analogy time: I was an amateur light heavyweight and I'm now Mike Tyson's size. I bet something interesting would happen if I get in the ring with him. Ow! Who do I sue for looking like the Hunchback of Notre Dame? I know, the Marquess of Queensbury!



  • <font face="Verdana" size="2">See, RyuO gets my point. I'm flat-out telling people not to use Oracle. I'm not selling anything. </font><font face="Verdana" size="2"> I'm not evangelizing the product.</font><font face="Verdana" size="2"> I'm trying to make your life easier.

    I like to write, so sometimes my verbosity gets in the way of my point. All the extra writing that goes beyond the main point -- feel free to ignore it. Or not. But basically, I'm posting in the "I-Hate-Oracle-Club" forum, and I'm saying "Don't use Oracle." I can't be any more clear than that.
    </font>



  • @Your Oracle DBA said:

    <font face="Verdana" size="2">See, RyuO gets my point. I'm flat-out telling people not to use Oracle. I'm not selling anything. </font><font face="Verdana" size="2"> I'm not evangelizing the product.</font><font face="Verdana" size="2"> I'm trying to make your life easier.

    I like to write, so sometimes my verbosity gets in the way of my point. All the extra writing that goes beyond the main point -- feel free to ignore it. Or not. But basically, I'm posting in the "I-Hate-Oracle-Club" forum, and I'm saying "Don't use Oracle." I can't be any more clear than that.
    </font>

    Just to be annoying, I'll pose the question: what should you do if somebody else makes the decision and hires you to do Oracle? I often tell clients they should be using PostgreSQL instead, and they always me to shut up and do Oracle. Those projects usually end badly.

    There are plenty of rational reasons people pick Oracle over something smaller and cheaper, which is not to say they are good reasons or sufficient reasons. Foremost is that it is easy to find Oracle people. Another reason is that the other commercial DBMSes give you even less for the money. A third is that if you buy a big league product, you look big league to other dumb people



  • @RyuO said:

    @Your Oracle DBA said:
    <font face="Verdana" size="2">See, RyuO gets my point. I'm flat-out telling people not to use Oracle. I'm not selling anything. </font><font face="Verdana" size="2"> I'm not evangelizing the product.</font><font face="Verdana" size="2"> I'm trying to make your life easier.

    I like to write, so sometimes my verbosity gets in the way of my point. All the extra writing that goes beyond the main point -- feel free to ignore it. Or not. But basically, I'm posting in the "I-Hate-Oracle-Club" forum, and I'm saying "Don't use Oracle." I can't be any more clear than that.
    </font>

    Just to be annoying, I'll pose the question: what should you do if somebody else makes the decision and hires you to do Oracle? I often tell clients they should be using PostgreSQL instead, and they always me to shut up and do Oracle. Those projects usually end badly.

    There are plenty of rational reasons people pick Oracle over something smaller and cheaper, which is not to say they are good reasons or sufficient reasons. Foremost is that it is easy to find Oracle people. Another reason is that the other commercial DBMSes give you even less for the money. A third is that if you buy a big league product, you look big league to other dumb people


    Now you are getting it.




  • I totally agree - I worked on an Oracle Datawarehousing project, spent a year as a DBA and now (thankfully) am back to Java programming.   

    Oracle is - to use the Australian Expression - a 'Brick Sh**house'.   Yes - it has features years ahead of any other database - but from a developer point of view the basics haven't changed in 10 (20? years) - and are frankly rubbish compared to more modern systems - for example:

     1) Column names, table names, foreign names etc are limited to 30 characters and must be unique in the schema- leading to helpful foreign key names like FK_CENTRAL_ACCOUNTS_T_CLIE43  - of course most people just give up and try and debug using the autogenerated foreign key names of FK012312312 - nice.   

     2) Error messages are rubbish - I'm sorry - but ' ORA-666 Invalid Identifier' - really helpful - doesn't tell  you what token was wrong - great when you have 1000s of characters of SQL to trawl through.

    3) Tracking the SQL executed on Oracle is difficult - yes you can turn on tracing but it kills performance and then you need to process the trace files (on the server of course) with TKPROF to read them!  (Oh and you really need a DBA to set it up for you)

    4) Most of the Oracle features work - but are a pain in the neck to implement - I remember sitting through a day of an Oracle training session where the instructor couldn't get Replication to work.   Transportable tablespaces are great as long as you know if your source and target OSs are bigendian or littleendian and how to change between the two.   

    5) Most modern databases have the concept multiple databases running under some umbrella process - with separate users, system tables, security for all of them - simple for maintainance and easy to use - not Oracle.   Anyone who has spent any time messing with public synonyms and cross schema priviliges will know what I mean here.

    6)  Oh and there are nice features such as storing empty strings as nulls - (hello - the two are DIFFERENT).

    Anyway - Oracle has heaps of features - but it is marketing driven rather than developer driven - and it is the developers that suffer. 

     

     

     



  • Rule #1: You cannot install and run Oracle yourself.

    Rule #2: You probably don't need Oracle.

    Rule #3: If you need Oracle, you'll know.

     ---------------

    haha. I went through the oracle dba training. I've rarely used it, never needed it, or recommended it once. I have met Oracle "DBA"'s that didn't know how to install a JVM on a sun box, at Citi. How can you be an Oracle DBA and not know how to install a jvm? (considering you need to install a jvm to use the installer, which you need to use to even DBA in the first place)?

    Certified experts? WTF? Take a class, pass a test, get to real world and unable to function. PAY ME!!! I AM AN EXPERT!!! HERE'S THE PAPER THAT PROVES IT!!! The scary thing is these guys had the titles "DBA" and "Senior Developer" and "Architect".

    >.<

    I walked into the issue and got Oracle running on the Sun box (having never been at a Sun command prompt before), in about 5 minutes, with them telling me all the stuff I was doing wrong the whole time o.O (+ the time it took for the software to install). ****ing retards. Then again I'm just an open source schlep, what do I know? (besides linux, unix, oracle, postgresql, mysql, mssql, php, perl, java, sh)? I won't get into how they kept bugging me to help them with PL/SQL. My title is "Developer".

     I'd never pass a sun or oracle certification, but when the chips are down, I deliver, and I don't waste 2 weeks before I ask for help, then blame the server guy that built the box for my own lack of knowledge and the lateness of my project.

    I can't wait till all this outsourcing goes horribly wrong and we get back to normal. I usually only have time to do my own job. 

    -viz 



  • [quote user="lofwyr"]

    One can only hope that you're really that good. I've seen too many "Oracle Specialists" in my career that were just mouthing off and were responsible for oversized and inferior solutions based on the said product.

    MySQL? Yes, it has its purpose - if you don't need views, triggers, stored procedures/packages, referential integrity, online backup capability, etc. Yes, I know, there are different "table types" - with different limitations. If you don't want Oracle (even the XE version) but still a database that serves its name, take a look at postgres, OpenIngres, MaxDB (also renamed to mysql?), even firebird would do for smaller applications.

    l.

    [/quote]

    I'm pretty sure he didn't mean to imply that the only choice is between MySQL and Oracle, and all businesses whose needs are way below Oracle's level must have it. That's why Sybase, SQL Server, and PostgreSQL exist, after all, a nice continuum of cost, features, and scalability. And <font size="-1"></font><font size="-1">Caché</font> for the trendster crowd. How some places can still get by on MySQL 3.2 blows my mind, though.

    (Sorry for reviving.) 



  • [quote user="viza"]haha. I went through the oracle dba training. I've rarely used it, never needed it, or recommended it once. I have met Oracle "DBA"'s that didn't know how to install a JVM on a sun box, at Citi. How can you be an Oracle DBA and not know how to install a jvm? (considering you need to install a jvm to use the installer, which you need to use to even DBA in the first place)?[/quote]

    You absolutely do NOT have to install a JVM to install Oracle. Any installation CD or tarball contains its own JVM. I also recommend, as does Oracle, that you not use any random JVM that you have laying around.

     [quote user="viza"]Certified experts? WTF? Take a class, pass a test, get to real world and unable to function. PAY ME!!! I AM AN EXPERT!!! HERE'S THE PAPER THAT PROVES IT!!! The scary thing is these guys had the titles "DBA" and "Senior Developer" and "Architect".[/quote]

    How is this different from any other type of certification from any other product certification? Most certifications are worthless.

     [quote user="viza"]I walked into the issue and got Oracle running on the Sun box (having never been at a Sun command prompt before), in about 5 minutes, with them telling me all the stuff I was doing wrong the whole time o.O (+ the time it took for the software to install). ****ing retards. Then again I'm just an open source schlep, what do I know? (besides linux, unix, oracle, postgresql, mysql, mssql, php, perl, java, sh)? I won't get into how they kept bugging me to help them with PL/SQL. My title is "Developer". [/quote]

    This is where your story kind of runs off its tracks. There are no circumstances in which you could have "got Oracle running" on a Sun box in 5 minutes. See, you can't even install Oracle on a Sun server without making some changes to kernel parameters in /etc/system and rebooting. Then doing an install, which isn't fast, even on top of the line Sun hardware. Even if you managed to hack up the installer packages to ignore all the pre-installation stuff that you didn't do, it wouldn't run without those kernel changes. Plus, a database has to be created. You designed and created that within that same 5 minutes? No? Oh, so you let Oracle install its default database, which would be completely worthless for almost any real use. Give me a break.

    If you got anything running at all in 5 minutes, it was set up to run before you ever got there. You may have discovered the startup commands needed in 5 minutes, but certainly no more than that.

    [quote user="viza"]I'd never pass a sun or oracle certification, but when the chips are down, I deliver, and I don't waste 2 weeks before I ask for help, then blame the server guy that built the box for my own lack of knowledge and the lateness of my project.

    I can't wait till all this outsourcing goes horribly wrong and we get back to normal. I usually only have time to do my own job. [/quote]

    I love L337 dudes like you, who think you know enough to conquer almost any task, without any real depth of knowledge about what you're doing. I interview people like you all the time, who tout the breadth of their skill sets and how they're great at everything, and I always give those people the thumbs down. People like you have great value in very small organizations, but in a larger development group, specialization is a good thing. I love L337 dudes like you because you make it very easy for us to spot you and weed you out. And I love L337 dudes like you because I know I'll always have work cleaning up the messes that you leave behind, because you really didn't have the knowledge to do what you set out to do in the first place. L337 dudes like you often (not always, mind you) leave ticking time bombs in every single thing they work on.

    Example: I'm doing a complete rebuild of our development environment next month due to someone like you, who was a self admitted jack-of-all-trades, who set up one of my SANs in such an incredibly stupid way that it has to be torn down and completely rebuilt from scratch before I can continue to use it. The guy who did the work is long gone (finally fired for his incompetence) but his legacy remains. It's only costing us about $400,000 in hardware and man hours to clean up his mistake.



  • [quote user="AlexBacon"]

    I totally agree - I worked on an Oracle Datawarehousing project, spent a year as a DBA and now (thankfully) am back to Java programming.   

    [/quote]

    I wasn't aware that the two were mutually exclusive. You sound like the sort of person I would not want writing Java code which talks to databases. A fairly important component of a lot of Java programming.

    [quote user="AlexBacon"]

    Oracle is - to use the Australian Expression - a 'Brick Sh**house'.   Yes - it has features years ahead of any other database - but from a developer point of view the basics haven't changed in 10 (20? years) - and are frankly rubbish compared to more modern systems

    [/quote]

    OK, then name these "more modern systems" and why they are so much better than Oracle. What's wrong with 'old' features? If they work? And haven't been improved on? (don't quote GOTO at me, please). And I think the Aussie (and British) expression is used to refer to something/someone being beefy, not huge and monolithic.

    [quote user="AlexBacon"]

    - for example:

     1) Column names, table names, foreign names etc are limited to 30 characters and must be unique in the schema- leading to helpful foreign key names like FK_CENTRAL_ACCOUNTS_T_CLIE43  - of course most people just give up and try and debug using the autogenerated foreign key names of FK012312312 - nice.   

    [/quote]

    There are many better ways of naming these things than your rather poxy example. If you can't fit a decent meaningful name into 30 characters you must be missing something somewhere. And what's wrong with unique names? You can't have duplicate filenames in a directory, or duplicate class names in a package, so why must you have duplicate names in a database schema? You can always qualify the name with the schema...

    [quote user="AlexBacon"]

     2) Error messages are rubbish - I'm sorry - but ' ORA-666 Invalid Identifier' - really helpful - doesn't tell  you what token was wrong - great when you have 1000s of characters of SQL to trawl through.

    [/quote]

    Now that I can agree with.

    [quote user="AlexBacon"]

    3) Tracking the SQL executed on Oracle is difficult - yes you can turn on tracing but it kills performance and then you need to process the trace files (on the server of course) with TKPROF to read them!  (Oh and you really need a DBA to set it up for you)

    [/quote]

    I'm sorry but you really will have to give an example of an alternative where this isn't a problem, otherwise this is just another spurious rant by someone who doesn't really understand how it all works. Name another system which flies like a bird with tracing/debugging switched on. You don't need tkprof to read these files, it just makes it easier. The files are on the server cos they are generated by the RDBMS, where would you expect them to be? And you only need the DBA to set it up because they can contain sensitive info and therefore usually have restricted permissions or are in a relatively inaccessible part of the filesystem. What exactly is wrong with any of that?

    [quote user="AlexBacon"]

    4) Most of the Oracle features work - but are a pain in the neck to implement - I remember sitting through a day of an Oracle training session where the instructor couldn't get Replication to work.   Transportable tablespaces are great as long as you know if your source and target OSs are bigendian or littleendian and how to change between the two.   

    [/quote]

    It's a shame when you get a rubbish instructor, or when the equipment doesn't work properly on a training course. I agree. Get over it. Transportable tablespaces? You needed to use something as advanced as that? Why you must have something pretty hefty to do. Oh dear, you need to know about the host's byte-order. Get over it. Find something genuine to whinge about for Godwins' sake.

    [quote user="AlexBacon"]

    5) Most modern databases have the concept multiple databases running under some umbrella process - with separate users, system tables, security for all of them - simple for maintainance and easy to use - not Oracle.   Anyone who has spent any time messing with public synonyms and cross schema priviliges will know what I mean here.

    [/quote]

    No, I'm sorry, I don't. Not sure what you're getting at here, but there is a whole raft of stuff available to implement fine-grained access control for example (http://www.orafusion.com/art_fgac.htm). This is within a single database of course; I will leave it to the experts to tell you about how Oracle can deal with other configurations.

    [quote user="AlexBacon"]

    6)  Oh and there are nice features such as storing empty strings as nulls - (hello - the two are DIFFERENT).

    [/quote]

    This is true, but I don't know how much of a problem that might be. I've worked as an Oracle developer for about 12 years and I've never had to worry about it. 

    [quote user="AlexBacon"]

    Anyway - Oracle has heaps of features - but it is marketing driven rather than developer driven  

    [/quote]

    Once again, that I can agree with.

    I should perhaps point out here that I'm not a 'fanboy' either, there are a lot of things I hate about it too. Eg. the three-way boolean functions - what's that all about! And the crappy way they implemented Reports (2.5/6i) on Windows. And Forms - any version. And the bloatware it's really become since Oracle 7. And the fact that three different supported pieces of software will not run in the same version of App Server, necessitating a near-30Gb installation. And the sh!te way it requires multiple ORACLE_HOMEs, but they never coexist quietly. And so on, and on.

    I just get fed up with lazy stuff like this.

    Oh, and I have a bit of time on my hands... 

     

     




  • Amazon uses MySQL.



  • [quote user="quamaretto"]Amazon uses MySQL.
    [/quote]

    I beg to differ - Amazon is predominantly, if not exclusively, an Oracle shop. I know for a fact that the stuff behind searching and buying is Oracle, and so is their "data warehouse", if there is only one. 

    Most, if not all, of the shopping front end is Java, and they don't use much in the way of stored procedures, if that makes you feel any better. Generally, Amazon techies are from the school that all "business logic" must be in the middle tier, so they are not using Oracle at full capacity. Why you'd buy Oracle and not use it the way it was intended has always been a mystery to me.

     



  • My cousin who works there told my this, but I could be misremembering. He was working on the "Used and new" marketplace thingy.



  • I actually find myself warming to this guy - I honestly thought you were going to disappear up your own arse during your introduction - but you didn't. Well done you!

    Superb rebuff; beautifully delivered; and so accurate. We have just run a benchmark test of Oracle. The quickest we could perform an install in a UNIX environment was a shade over 2 hours and our guy's got many years of Oracle DBA experience.

    I think the assertion that most data management tasks can be performed without the use of Oracle is sound. I wonder if you could elaborate and suggest the type of applications for which you would use Oracle. You've suggested, for example, that telecommunication companies need Oracle but you haven't said what type of applications within a telecommunications business might need it.



  • @RyuO said:

    @quamaretto said:

    Amazon uses MySQL.

    I beg to differ - Amazon is predominantly, if not exclusively, an Oracle shop. I know for a fact that the stuff behind searching and buying is Oracle, and so is their "data warehouse", if there is only one. 

    Most, if not all, of the shopping front end is Java, and they don't use much in the way of stored procedures, if that makes you feel any better. Generally, Amazon techies are from the school that all "business logic" must be in the middle tier, so they are not using Oracle at full capacity. Why you'd buy Oracle and not use it the way it was intended has always been a mystery to me.

     

    maybe some BS story to mgmt about being able to swap out the database engine in the future???



  • That's one reason - it was an especially popular notion in the dotbomb area. Every couple years I see a company switch from something else to Oracle, but in 24 years I've never seen anyone switch away from Oracle. Being DBMS-independent is a good idea if you want to end up in Oracle, but making that decision guarantees that you will end up in Oracle. You might as well do it first time and save money, not to mention your job. Postgres is something of an exception to this principle because it is so similar to Oracle - you can even convert the stored procedures easily.

    The other reason I see is that poorly educated developers can't shake the notion that a DBMS is/resembles a file system. Therefore they use it as if it were a file system, and if they're lucky all they do is waste money.

     This forum's clientele has many of the second category: there are hundreds of posts that, once you factor them down, amount to "Oracle is way too complicated for a file system" and "DBMS X is better because it's less complicated". The former is completely true as far as it goes, and the latter is true to the extent that DBMS X can be used as a file system. My wife thinks my Vette should carry all the kids and family gear too.
     



  • I found that post very rewarding.  Thank you so much. Talk all the shit you want about oracle, bottom line, it pays the bills like a mother fucker. I gotta go remember where i put that ora file gah.



  • I DON'T NEED YOU

    I did 2 ora database projects. My clients luckily did want plsql and ora forms so i convinced them using oledb and .net code (what they insisted was only oracle oracle oracle and oracle database). So I did write 100% ansi  with only substr, to_date and current_date from ora.

    after 1 year of operation, they asked me to port to sql server because they could not (and could not find anybody) to do backup ora database (i told them i would not do dba for them). Guess what happened: I posted to SQL server in 2 days and that was it.

    I encounted several minor problems at installing ora 9i like NullPointer exception at java.lang and 50 other java classes, had to reinstall 3 times because antivirusware killed oracle.exe and other oracle files (why the antivirusware did not kill other software in the client computer, or did it think oracle.exe was a VIRUS - which really was by eating up all the resosources).

    after all escaped ellison with minor injuries and my clients are now happy with sql server that they can backup and restore ....



  • Really F U C K - O R A C L E

    @tbtvn said:

    I did 2 ora database projects. My clients luckily did want plsql and ora forms so i convinced them using oledb and .net code (what they insisted was only oracle oracle oracle and oracle database). So I did write 100% ansi with only substr, to_date and current_date from ora.

    I'm Totaly Agreed with you that most people are just deceived by the fake propaganda of ORACLE and almost all top management level commitment to go ORACLE are fooled by sale reps from allover the world.

    I've gone for two oracle projects now that are done this way without any person in the whole company knows why just we have this fucking stupid product.

    From my PointOfView I think that oracle designs a products just for those strange creatures who lives on other planets, it is not for humans at all. believe me it could be more more simpler than that I don't understand why the stupidity ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! ! !



  • Funny read...

    My main complain with Oracle is how hard it is to do anything simple.  That, on its own, tells me I don't need Oracle.  And I don't.  But my customers think they need Oracle with my product, or they just use Oracle for everything by policy.  And that means that I do need Oracle, if only once in a blue moon, for testing and debugging.

    The big one: I have yet to install Oracle successfully on Unix.  Now I've only tried a few times, but my Unix skills are up there... it shouldn't be that hard to do a simple install, for test/development purposes.  I don't need performance here, I just need the darned thing to work.

    Reminds me of my upper-year CS courses, where TA's would respond to student questions about design choices with, "Choose something reasonable and document it."  I wish I could tell Oracle to "do something reasonable".

    For not being a DBA, I can do a decent job with SQL, in a generic sense.  I can design reasonable data models.  I can write good queries.  I know my indexes from my keys, and how to reasonably use them.  Too bad that has nothing to do with the skill set required to install Oracle. 



  • @AssimilatedByBorg said:

    Funny read...

    My main complain with Oracle is how hard it is to do anything simple.  That, on its own, tells me I don't need Oracle.  And I don't.  But my customers think they need Oracle with my product, or they just use Oracle for everything by policy.  And that means that I do need Oracle, if only once in a blue moon, for testing and debugging.

    The big one: I have yet to install Oracle successfully on Unix.  Now I've only tried a few times, but my Unix skills are up there... it shouldn't be that hard to do a simple install, for test/development purposes.  I don't need performance here, I just need the darned thing to work.

    Reminds me of my upper-year CS courses, where TA's would respond to student questions about design choices with, "Choose something reasonable and document it."  I wish I could tell Oracle to "do something reasonable".

    For not being a DBA, I can do a decent job with SQL, in a generic sense.  I can design reasonable data models.  I can write good queries.  I know my indexes from my keys, and how to reasonably use them.  Too bad that has nothing to do with the skill set required to install Oracle. 

    Something's not right with this story - on supported OSes, you can usually follow the docs blindly. That's if you know something about the OS: the most trouble I ever got into was in my first Solaris install where I didn't bother to learn anything about Solaris "slices" and "semaphores" first. After the OS humbled me I had no problems. I've even taken a Linux Oracle distro and got it to run in BSD, and I didn't need to know much about the Oracle deltas to do so.

    However, If you want to complain about Oracle on Unix, you need look no further than Patches. Oracle has historically done a terrible job of documenting dot releases, and you sometimes end up installing a cumulative release, only to find out the hard way that the release was *not* cumulative with the previous one.

    I assume we're talking about Oracle Enterprise Edition here, which is made for *big* databases that are so expensive the DBA is expected to know what he's doing. If you want a version of Oracle that is about as easy to install and use as SQL Server or MySQL, you want Oracle XE, which is made for developers.



  • @RyuO said:

    @AssimilatedByBorg said:

    Funny read...

    My main complain with Oracle is how hard it is to do anything simple.  That, on its own, tells me I don't need Oracle.  And I don't.  But my customers think they need Oracle with my product, or they just use Oracle for everything by policy.  And that means that I do need Oracle, if only once in a blue moon, for testing and debugging.

    The big one: I have yet to install Oracle successfully on Unix.  Now I've only tried a few times, but my Unix skills are up there... it shouldn't be that hard to do a simple install, for test/development purposes.  I don't need performance here, I just need the darned thing to work.

    Reminds me of my upper-year CS courses, where TA's would respond to student questions about design choices with, "Choose something reasonable and document it."  I wish I could tell Oracle to "do something reasonable".

    For not being a DBA, I can do a decent job with SQL, in a generic sense.  I can design reasonable data models.  I can write good queries.  I know my indexes from my keys, and how to reasonably use them.  Too bad that has nothing to do with the skill set required to install Oracle. 

    Something's not right with this story - on supported OSes, you can usually follow the docs blindly.

    [snip] 

    I assume we're talking about Oracle Enterprise Edition here, which is made for *big* databases that are so expensive the DBA is expected to know what he's doing. If you want a version of Oracle that is about as easy to install and use as SQL Server or MySQL, you want Oracle XE, which is made for developers.

    Sure, what's not right with the story is "me" combined with Oracle :-)

    Maybe I used the wrong version of Oracle for my purposes.  Maybe I didn't follow the docs correctly.  Maybe my Solaris box was misconfigured in some other way.  I'll happily take the blame for screwing up.  But I'm equally happy to blame Oracle for giving me so much rope with which to hang myself. 

    SQL Server?  MySQL?  Postgres?  Got 'em all working, no problems.  Oracle?  Let's just say we have a hate-hate relationship.


Log in to reply