The tale of the imploding database



  • ... so once more, my database has imploded.

    As in, "spends all its time in iowait, while blissfully blaming everyone else for the server being slow"

    As in, "will sit on its fat arse instead of shutting down, unless you tell it to abort"

    As in, "pretends you can log in, but woe to him that tries to run a command".

     
    This is about the fifth time that I delete a database and create a completely new one just to be able to *work*. How on earth this piece of bat excrement ever left Larry Ellison's basement is beyond me. This time it was the actual database going titsup, but I've had just about every piece of this ramshackle excuse for a RDBMS go catatonic for no apparent reason.

    Add to that that it's slower than treacle, eats memory like it was designed by Corsair, handles unicode worse than a dyslexic ball of snot, will completely fuck up your data for very arcane and obscure reasons reminiscent of a Kafka novel, and I am at a loss why anyone would touch it other than at the business end of a lawsuit. Or a shotgun.

     

    Fucking. Piece. Of. Crap.



  • ... and to turn insult to injury, after creating the new incarnation, my em console came up in the oh-so-familiar mode of "nah-uh, it's down (which, of course, it really isn't) and I'm not going to let you do anything about it"

    *cries* 



  • Well, you could start reading the documentation and book some courses or move to something less demanding, like mysql. I know, it's far easier to blame the product than trying to learn something.

     l.
     



  • No. Just no. 

    Our product currently supports Postgresql, SQL Server, Sybase, Sqlite and Oracle. I'm currently writing MySQL support. Oracle far outshines the rest COMBINED in how much crap it's giving us. I only work with it because I'm forced to.

    I'm well aware that Oracle normally targets servers that are far larger than our normal devel servers. I'm also well aware that I've only taught myself as little Oracle-fu as I could get away with (because eating turds gets old fast). It's still a fact that Oracle consumes an outrageous amount of resources and hand-holding to do the exact same work as the others. And it's general tendency to go catatonic is simply unacceptable in *any* RDBMS.



  • [quote user="Armillary"]

    No. Just no. 

    [/quote]

    Yes. Simply yes. 

    [quote user="Armillary"]

    Our product currently supports Postgresql, SQL Server, Sybase, Sqlite and Oracle.

    [/quote]

    Hmm, I'm missing at least DB2 there. Anyway, since sqlite is also mentioned, I hate to think of what your application does do access sqlite and Oracle. Same goes for Oracle vs. sqlserver. 

    [quote user="Armillary"] 

    I'm currently writing MySQL support. Oracle far outshines the rest COMBINED in how much crap it's giving us. I only work with it because I'm forced to.

    [/quote]

    Well, if you're trying to work with Oracle the way you're working with mysql, I'm afraid crap is all you're going to end up with. You could of course take a look at the documentation, but I'd say according to your last statement, this won't happen.

    [quote user="Armillary"] 

    I'm well aware that Oracle normally targets servers that are far larger than our normal devel servers.

    [/quote] 

    Incorrect assumption, since you can now use Oracle XE. Or your development servers are even smaller than my old Desktop machine at home.

    [quote user="Armillary"] 

    I'm also well aware that I've only taught myself as little Oracle-fu as I could get away with (because eating turds gets old fast).

    [/quote] 

    Again, wrong approach. Have you been as sloppy when you've taught yourself mysql or any other mentioned major database? 

    [quote user="Armillary"] 

    It's still a fact that Oracle consumes an outrageous amount of resources and hand-holding to do the exact same work as the others.  And it's general tendency to go catatonic is simply unacceptable in any RDBMS.
    [/quote] 

    Bzzzt. Wrong again. Oracle XE comes as .deb or .rpm package, total install time including Ubuntu SVR 6.06 LTS: about 30 minutes, and requires 512 MB RAM and a couple of GB space on the harddrive. Yes, that's more than mysql or sqlite, but don't tell me you were expecting to fit everything in 640K RAM and a floppy disk. And for going catatonic: you could take a look at trace files/logs to find out what's going on, but that would mean you'd have to take a look at the documentation again. I don't see how that's going to happen with the given attitute you show - which I consider a bit unprofessional.

    l.



  • Duplicate post. *sigh*



  • Having a complex feature-rich product that requires documentation to understand is pefectly okay. I draw an analogy with the high-end 3D packages like XSI, Houdini, Max, Cinema. There's no way you're going to be productive in those without pressing F1. A lot.

    But from what I can tell (browsing this forum), Oracle is using it as an excuse to completely avoid putting energy in making things easy.

    Having (extensive) documentation is not a valid reason to keep things hard if they can be made easy(er). "Just look it up" is a crap excuse.

     



  • Is it? Yes, Oracle has its irks, as does have any other product. However, I don't understand how getting fundamentals of any product can made up any easier than reading them up? Each version, Oracle managed to improve on the usability, but there will always be a learning curve, because of the provided features. If people don't want that, they should stay with text files, a DBMS is not a toy.

     l.



  • [quote user="lofwyr"]

    However, I don't understand how getting fundamentals of any product can made up any easier than reading them up?

    [/quote]

    Some programs are easy to install, intuitively usable, come with reasonable default settings and ahere to standards. For such programs, an experienced user normally doesn't have to read up too much.



  • Well with  "some programs", "intuetively usable", "reasonable default settings", "standards" and "experienced user" we'll have a wide field - and some new kind of buzzword bingo. Have we entered Dilbert space yet?

     

    l. 



  • Get off your high horse, fanboi. Some of us aren't high and mighty DBAs with eleventyseven million $ of Oracle courses under our hat. I just have the misfortune to have to work with what passes for an API against various databases. Views, triggers, stored procedures - all that crap is of zero use to me, and I'd never pretend otherwise. As far as I'm concerned, the less a DB manipulates the data I put into it, the happier I am.

    So, how does Oracle support me in this?

    * ObEscapeTheBloodyEmptyStrings - check

    * Violates its own 4000 byte constraint for nvarchar2 - try anything over 1333 bytes, and it'll fill up your column with garbage instead of, oh, give an error code or something useful. And yes, I mean bytes, not characters. I UTF-8 encoded them myself. And straight USASCII too...

     

    * Data returned in a pretty random LOB container type - check. It seems to be about 50/50 if I get a CLOB or NCLOB. Which meant no end of fun trying to figure out what charset to feed OCILobRead.

    Nifty!

    Friggin overcomplicated POS. 

     And further FYI, just because we *can* work with Sqlite doesn't mean it's recommended to do anything complicated with it - those cartesian joins mean long coffee breaks once you go over 4-5 table joins. Works well for development purposes though, and maintaining test databases with gzip and mv is handy.

    // Armillary



  • [quote user="Armillary"]

    Get off your high horse, fanboi.

    [/quote]

    Why thank you, coming from an illiterate I could consider this as a compliment.

     


    Some of us aren't high and mighty DBAs with eleventyseven million $ of Oracle courses under our hat.

     

    a) I'm a developer, not a DBA. b) I've had exactly one Oracle course so far: Oracle Forms c) Did I mention that I can read documentation? 

     


    I just have the misfortune to have to work with what passes for an API against various databases. Views, triggers, stored procedures - all that crap is of zero use to me, and I'd never pretend otherwise. As far as I'm concerned, the less a DB manipulates the data I put into it, the happier I am.

    If you want to reinvent the wheel, sure, go ahead. Are we talking about another guest book, content management system or anything else that doesn't require lots of user connections and data? Hey, why not move to text files?


    So, how does Oracle support me in this?

    * ObEscapeTheBloodyEmptyStrings - check

    Yes, that's something that has been discussed do death.  Yes, '' = NULL wasn't their best idea.


    * Violates its own 4000 byte constraint for nvarchar2 - try anything over 1333 bytes, and it'll fill up your column with garbage instead of, oh, give an error code or something useful. And yes, I mean bytes, not characters. I UTF-8 encoded them myself. And straight USASCII too...

    I just keep wondering why you're doing this. If it's a bug, then check for metalink. And if you have to use bigger fields, use NCLOB. 

    * Data returned in a pretty random LOB container type - check. It seems to be about 50/50 if I get a CLOB or NCLOB. Which meant no end of fun trying to figure out what charset to feed OCILobRead.

    Sorry, I don't do NCLOB right now. Since you don't mention version and patch level either, it would be 20 questions from this on, and since we already discussed the documentation thingy ... 

     

    Nifty!

    Friggin overcomplicated POS. 

     And further FYI, just because we can work with Sqlite doesn't mean it's recommended to do anything complicated with it - those cartesian joins mean long coffee breaks once you go over 4-5 table joins. Works well for development purposes though, and maintaining test databases with gzip and mv is handy.

    I'd never figured that one out after reading some documentation on sqlite (and noticing that id doesn't come with any sophisticated optimzer). Development with mv and gzip may be fun, I suppose I'll stay with development databases and PL/SQL.

    l. 



  • [quote user="Armillary"]

    Get off your high horse, fanboi. Some of us aren't high and mighty DBAs with eleventyseven million $ of Oracle courses under our hat. I just have the misfortune to have to work with what passes for an API against various databases. Views, triggers, stored procedures - all that crap is of zero use to me, and I'd never pretend otherwise. As far as I'm concerned, the less a DB manipulates the data I put into it, the happier I am.

    [/quote]

    I am a Remote DBA & Developer and have had not the single Oracle class...I like to do this thing called reading, where you actually use other people's knowledge to do things...very useful trick you might want to pick up...have my Oracle 10g DBA OCA just by reading (and doing)

    [quote user="Armillary"]

    So, how does Oracle support me in this?

    [/quote]

    Metalink is pay for, but the forums are free...just try to actually ask a question without tossing blame around...remember, it might be you

    [quote user="Armillary"]

    * Data returned in a pretty random LOB container type - check. It seems to be about 50/50 if I get a CLOB or NCLOB. Which meant no end of fun trying to figure out what charset to feed OCILobRead.

    [/quote]

    Well, this really relates to my old principle of GIGO...garbage in garbage out. If you don't know what you are putting in the database, I can certain guess that you are going to have a hard time getting something out of it, now aren't you... 

    [quote user="Armillary"]

    Friggin overcomplicated POS. 

    [/quote]

    It is only as complicated as you want it to be...as all of the information is out there, and even the software is free to download and try to work with.



  • [quote user="lofwyr"]

    Well with  "some programs", "intuetively usable", "reasonable default settings", "standards" and "experienced user" we'll have a wide field - and some new kind of buzzword bingo. Have we entered Dilbert space yet?

    [/quote]

    If those words mean nothing to you, it's probably because you have spent too much time with systems where those words have no meaning.



  • [quote user="ammoQ"]

    If those words mean nothing to you, it's probably because you have spent too much time with systems where those words have no meaning.

    [/quote]

    Oh, they have a meaning - unfortunately they differ depending on given tasks and the complexity of products. But if you expect that developing with a database has to be as intuetively usable as for example listening with a mp3-player, I'm afraid this will yet be another endless discussion, which I don't want to get into. Another "agree to disagree" case, I suppose.


    l. 



  • Oracle's XE proves that the installation of a database system doesn't have to be painfull and complicated. Now if only they could have make it that easy 10 years earlier..



  • [quote user="ammoQ"]Oracle's XE proves that the installation of a database system doesn't have to be painfull and complicated. Now if only they could have make it that easy 10 years earlier..
    [/quote]

    Oracle XE comes with a reduced set of features. SE and EE offer additional options that would mean loads of rpm/deb-Packages to allow for any possible combination. And even in XE you would have to change init Parameters depending on your requirements - as in any other database product - since nobody knows how many connections/memory/etc. the final installation needs. And we shouldn't forget, that some people have even problems with the installation of XE, like adding swap space or setting up the firewall.

    However, for special purposes, companies like HP offer installation kits, for example for setting up a RAC. I doubt, however, that without any background knowledge and the attitude of other posters to ignore documentation, that this would result into high quality installations.

     l. 



  • Hi.

     I have been following this for a while now and I cud not agree more that the key is to read up on stuff and the bigger key is probably good forums (not the I hate types...). The lazydba for eg is a great place to ask questions but bashing Oracle or any other Db package is not the solution, in fact quite the contrary it becomes the problem. I have been a self-taught SQL Server and Oracle DBA for 10 years+ (ie. before i went for the actual courses) and find that both RDBMS packages come with the good and the bad but the one thing common to both is that they are both great products and need READING.

    My 2 cents...

     AK



  • @lofwyr said:

    @Armillary said:

    Our product currently supports Postgresql, SQL Server, Sybase, Sqlite and Oracle.

    Hmm, I'm missing at least DB2 there. Anyway, since sqlite is also mentioned, I hate to think of what your application does do access sqlite and Oracle. Same goes for Oracle vs. sqlserver. 

    Missing DB2 too, but I've also done multi DB code (Firebird, Mysql, Postgres, Sql-Server, DB2 & Oracle). I can tell you that any DB manager can read simple SQL,  but Oracle.

    It is up to the point where you can machine translate your code from any DB to any other, except Oracle, that restricts table, fields and constraint names, deals differently with default values and inserts bugs on your code by changing the the data (yep, a database that changes your data... If it wasn't Oracle, we could laught).

    @lofwyr said:

    @Armillary said:

     

    I'm also well aware that I've only taught myself as little Oracle-fu as I could get away with (because eating turds gets old fast).

     

    Again, wrong approach. Have you been as sloppy when you've taught yourself mysql or any other mentioned major database? 

    I bet he just uses some plain SQL, and learned some administrative commands for the other databases. It is not like you need a different language to interface with each DB, we have a standard for that. You just need to learn a new language to interface with Oracle. 

    @lofwyr said:


    @Armillary said:

     

    It's still a fact that Oracle consumes an outrageous amount of resources and hand-holding to do the exact same work as the others.  And it's general tendency to go catatonic is simply unacceptable in *any* RDBMS.

     

    Bzzzt. Wrong again. Oracle XE comes as .deb or .rpm package, total install time including Ubuntu SVR 6.06 LTS: about 30 minutes, and requires 512 MB RAM and a couple of GB space on the harddrive. Yes, that's more than mysql or sqlite, but don't tell me you were expecting to fit everything in 640K RAM and a floppy disk. And for going catatonic: you could take a look at trace files/logs to find out what's going on, but that would mean you'd have to take a look at the documentation again. I don't see how that's going to happen with the given attitute you show - which I consider a bit unprofessional.

     

    Installing Oracle XE on Linux on 30 minutes!!!!! LOL (hey I never used that). Last time I tried, I had even to replace Bash, so the installer would work (on Windows it is easier).

    And I can atest that it does go catatonic, and says everything is working just fine. I don't really remember how I fixed this problem at my test server when it happened (I used it to develop packaaged software, so there was no inhouse deployment, and we didn't support Oracle deployment, only Mysql and Firefird), but it required some very deep hacking.

    Anyway, once working is stays working... Quite like Postgres :)



  • @Mcoder said:

    Missing DB2 too, but I've also done multi DB code (Firebird, Mysql, Postgres, Sql-Server, DB2 & Oracle). I can tell you that any DB manager can read simple SQL,  but Oracle.

    And how far will "simple SQL" get you, regarding different transaction models?

    @Mcoder said:


    It is up to the point where you can machine translate your code from any DB to any other, except Oracle, that restricts table, fields and constraint names, deals differently with default values and inserts bugs on your code by changing the the data (yep, a database that changes your data... If it wasn't Oracle, we could laught).

    The restriction on the length of object names can be annoying, yes. Deals differently with default values? Bugs in your code by changing data? Never encountered that behaviour myself - you do have a test case to prove your point, right?
     

    @Mcoder said:


    I bet he just uses some plain SQL, and learned some administrative commands for the other databases. It is not like you need a different language to interface with each DB, we have a standard for that. You just need to learn a new language to interface with Oracle. 

    Plain SQL may be some sort of interface, but what about triggers and stored procedures? Is SQLPL(DB2) compatible to T-SQL (Sybase)? Or are you just using the database as bit bucket?

    @Mcoder said:


    Installing Oracle XE on Linux on 30 minutes!!!!! LOL (hey I never used that). Last time I tried, I had even to replace Bash, so the installer would work (on Windows it is easier).

    I didn't have to do that with recent Linux distributions (Ubuntu SVR 6.06 LTS for example). As I said, 30 minutes for a standard configuration if you know what you're doing. Never tried the Windows installation though. 

     

    @Mcoder said:

     

    And I can atest that it does go catatonic, and says everything is working just fine. I don't really remember how I fixed this problem at my test server when it happened (I used it to develop packaaged software, so there was no inhouse deployment, and we didn't support Oracle deployment, only Mysql and Firefird), but it required some very deep hacking.

    Doesn't sound very convincing to me if you even can't remember the problem and it's solution. I'm not arguing that Oracle may have it's bugs and problems, but those are vague discriptions of a possible problem at best. 

    @Mcoder said:

     

    Anyway, once working is stays working... Quite like Postgres :)

    Postgres looks very promising. Without the features of PL/SQL however I think I'll stay with Oracle.

    l.
     



  • Your database spends all its time in Iowa?  Dude, that's messed up!

     Oh, waittaminnit.... may have misread that.

     

     



  • Lofwyr's speaking for me too. Couple extra points:

    • Oracle has always been easy to install on Windows, and easy in Linux since version 9.2 or so. Solaris is slightly more difficult, but that's Sun's fault. Don't get creative with any of the pre-installation tasks, though.
    • Oracle's online documentation at otn.oracle.com is very good. Starting with the Concepts guide is a a good idea, or you may have a hard time figuring out what pertains to you.
    • The quality of Oracle books is very high compared to most technologies. Any book by Tom Kyte is a good starting point, and his website, asktom.oracle.com, is the best forum out there.
    • I've never personally seen a newbie hose themselves the way Armillary did. Once I spun up a team of junior programmers in a matter of months without any major pain. The biggest problem was not technical minutiae, but shifting paradigms from OO languages to SQL. 

     


Log in to reply