Re: Informix vs. Oracle

Keith, Kevin, et al: First, the only benchmarks that mean anything are when you benchmark your own applications against your own data, or as closely simulated as you can get. In that forum I have NEVER seen Oracle beat Informix on the same hardware and dataset, not in 17 years of doing this! OK Oracle did win a benchmark here at Bloomberg, later we discovered they had altered the schema changing data types and record formats and they neglected to inform us that they had failed to load up 1/3 of the sample data we gave them! And while they reported loading 50% more rows per hour than the Informix test (which was already in and done before they started) they did not bring up the Bloomberg runtime environment so there would be normal system traffic during the test which were the specified conditions under which they were supposed to test and under which Informix did test. I have to discount results like that and I did. Let's address the TPC benchmarks. First, Informix has not published any in a while and while politically that is BAD BAD BAD, Informix is famous for marketing and PR blunders and that one takes the bait. Next Oracle admitted to tweaking the operation of their optimizer to select query paths that favor the performance of certain critical portions of the TPC benchmarks to the detriment of query speed in general (there are reasons why most serious Oracle DBAs shy away from using the Cost Based Optimizer). Third the Oracle results do not show the result of scaling up the dataset size or the number of users, these are always selected to avoid showing the severe performance drop off, certainly compared to Informix, of increasing database size and increasing numbers of users. Ever notice that they do not test on a Sun E650 with 24 CPUS or an E10000 with 32 CPUs? That is because Oracle does not take good advantage of all those resources! Keith, if you really want to see which server is better bring both companies in to prove themselves. Heck Informix even set up a bunch of testing centers across the world so potential customers could bring in their data and apps and spend several days (or more) playing and testing and tweaking and tuning (all with an Informix consultant within earshot to help out)! Does Oracle offer this service, I'd say they dare not! Yeah, management types like Oracle better than Informix because Informix could not sell plastic carry bags to supermarkets, but the DBA that has used both and prefers Oracle to Informix is a rare bird indeed. "Hayward, Kevin" wrote: > > Keith > As with most people that dislike change but it is not all that > bad as long as you understand the fundamental principles behind a > relational database. I have used both databases for several years and > personally I prefer Oracle to Informix. I am sure that the biggest > reason that your management wants to switch to Oracle is that 99% ( > Everyone but Documentum) of DMS vendors do not support Informix but do > support Oracle. As far as speed Oracle wins hands down. Go see for > yourself at www.tpc.org <http://www.tpc.org>; this is a third party > organization that all the big database players belong to in the pure > speed section Informix does not even show up in the top ten. Do not be > fooled Oracle takes a lot of time and analysis and tweaking to get into > a fine tuned state. Informix on the other hand out of the box runs What tweaking? THERE ARE DAMN FEW TUNABLES! Compare the various tunables already in your ONCONFIG file, plus the ones documented in the Administrator's Guide, and the dozen or so new tunables that have not been around long enough to have been documented yet to the paltry few tunables in the Oracle control file. What do they amount to? Number of buffers, page size, block (extent) size, global shared memory area (TPA?), that's about it. When IDS first came out I was the first to complain that there were too many tunables but I have since learned that different databases and applications have performance needs so different that you simply cannot tune an engine for any one of them without the flexibility of tuning everything from how many tables' catalog records and data distributions get cached (separate tunables), to how many pages to read ahead while doing a sequential scan, to whether the optimizer should favor nested loop joins or hashed joins or just decide itself based on pure cost (which unlike Oracle's Cost Based Optimizer it does darn well BTW), to whether to age high priority data pages that have not been accessed recently so that more lower priority pages can be cached or not to, and on and on. Kevin is right, IDS DOES run fairly well out of the box, for a small transaction based database application like the TCP-A, B, & C, strange that Oracle does not (you would think the engine would have reasonable and useful defaults eh?) but that's an aside. But most of us are not running a small transaction based system. And few of us are not running systems remotely like each other's systems either! That is why I will say in this forum, "Well I tune that like this and get good results", and someone else can say, "We tried that and it did not help but we pushed this one down instead and the performance improved" and we will each be correct for our systems and the way we use them. > fairly well just out of the box. If you don't really care about > performance and don't want to spend the time learning the ins and outs > of your engine stay with Informix. The only other thing would be the > backups as far as disaster recovery there both about the same. For I ARRRGGGHHH! Go to W. Curtis Preston's WEB Site and read all about how good Oracle's backups are (Curtis is a SysAdmin who only cares about the quality and security of his archives, rightly so, with no bones to pick). To get a useful, secure, safe hot backup you have to archive each tablespace (read disk or chunk) separately then since they are out of sync you have to move the redo logs to their archive file and start a new redo log, backup the redo logs so that after restore you can roll forward the redo logs (probably manually I don't know) to resync the tablespaces, now don't forget to back up the control file or if there is a catastrophic crash you cannot restore anything since the location information about where to place those restored files is not on the archive tape! Contrast that to doing a hot backup (read online archive) in Informix: run ontape -s -L 0 or onbar or your normal system backup using LegatoNetworker (or whatever xBSA compliant backup system you use) and it will start onbar for you, change tapes as needed, remove tapes! No Kevin Oracle and Informix are NOT the same for archiving. > screwed up and need to restore a table back to a certain point in time > Oracle wins Informix has some major flaws in there thinking the Umm yes Informix cannot restore a single table from a system level archive unless that table lives in its own private dbspace(s) since the lowest level of restore granularity is the dbspace which CAN be restored to point-in-time with onbar and nearly so with ontape (log file granularity). BUT Oracle cannot restore a single table from that system level hot backup either! Only from table level backup

Just to keep the debate informed ... > The Oracle results do not show the result of scaling up > the dataset size or the number of users, these are always selected to > avoid showing the severe performance drop off, certainly compared to > Informix, of increasing database size and increasing numbers of users. http://www.tpc.org/new_result/c-result1.idc?id=98101303 http://www.tpc.org/new_result/c-result1.idc?id=98121801 > Ever notice that they do not test on a Sun E650 with 24 CPUS or an E10000 > with 32 CPUs? That is because Oracle does not take good advantage of all > those resources! http://www.tpc.org/new_result/c-result1.idc?id=99032301 > Keith, if you really want to see which server is better bring both > companies in to prove themselves. Absolutely -- Regards, Mark Townsend

Mark Townsend wrote: > > Just to keep the debate informed ... Thanks Mark. But read on. > > The Oracle results do not show the result of scaling up > > the dataset size or the number of users, these are always selected to > > avoid showing the severe performance drop off, certainly compared to > > Informix, of increasing database size and increasing numbers of users. > > http://www.tpc.org/new_result/c-result1.idc?id=98101303 > http://www.tpc.org/new_result/c-result1.idc?id=98121801 OK, the tests are there. What do they show? These benchmarks DO use 32 & 64 Intel Xeon CPUs but only show 4 & 8 clients simulating users. Also note the doubling the number of CPUs and clients did NOT quite double the throughput (48,793 -vs- 93,900) and the cost per transaction goes up from the first to the second. Check out the, admittedly very old (7.23), Informix benchmarks shown at the site which show a much better scalability with the cost per transaction dropping almost 25% with closer to double the throughput. This on IDS7.23 when 7.24, 7.30, and 7.31 each has posted user verified performance inprovements while the Oracle 8i benchmarks look comparable to the Oracle 8 benchmarks. Bottom line is that Informix has NOT posted recent benchmarks, nor any on comparable platforms to these. Therefore there is limited value to using them for performance comparison. > > Ever notice that they do not test on a Sun E650 with 24 CPUS or an E10000 > > with 32 CPUs? That is because Oracle does not take good advantage of all > > those resources! > > http://www.tpc.org/new_result/c-result1.idc?id=99032301 This shows 64 Sun CPUs on a Sun E10000 with 32 clients. With results only about 15% better than the test above with 64, slower, Xeon CPUs and only 8 clients! Where is the scaling? > > Keith, if you really want to see which server is better bring both > > companies in to prove themselves. > > Absolutely Sanity. Thanks. I don't think my point is lost. The benchmarks do not show Oracle doing the kinds of things that I feel Informix does better than they and one of those is to scale better to more hardware, more clients, and larger datasets. Art S. Kagel