Re: Informix beats Oracle

DA Morgan wrote: >> I meant it's lighter than Oracle. Uses less hardware. > > I didn't disagree. But my point was that the difference works out to > about $11.25 at retail ... in other words the difference given today's > hardware prices is inconsequential. Hardware is not necessarily just disk... > I can run essentially any RDBMS in 256MB of RAM on any Pentium. If I > don't need much more than that I go with MySQL or Oracle's free > Application Express. If I need more than that then I'm running SAP or > Siebel or PeopleSoft, etc. so the horsepower required is, again, So, in your world or vision of the world there is nothing between 256MB of RAM and 3rd party enterprise resource or CRM software. I'm glad to inform you, that I probably live in 2nd life :) > financially inconsequential. I can't imagine made the change they did > for the reason you list. Seems more likely it was due to their desire > to keep it from competing with DB2 and sell as an embedded database: > What CA did with Ingres before they through in the towel and gave it away. Any reader can choose between what I said, and what you imagine in your dreams. > $ rman target /> RMAN> backup database; > > can you make it simpler than that? > > If you did would the benefit be palpable? So simple it almost look like ontape :) You're obviously ignoring the configuration steps, which could be reduced to something similar to ontape config, but just looking at the manual will scare many :) But we could talk about onstat... or not... :) The problem here are the habits... Ontape is easy (although limited) for ages... RMAN is finally easy... And it also brought great advances like incremental backups :> I call it advances and not innovations, since it's last millennium stuff! > The question I would put to you with respect to innovation would be to > compare the features of Cheetah, just released, with Oracle 11g, soon to > be released. Is the innovation there or is it playing catch-up with SQL > Server? -Don't know nothing about SQL server and I'm too lazy to look for... But will 11g bring multiple active (although readonly) databases? Your answer is RAC... nice... But for some purposes I really don't want all the queries in the same disks (I even may want a server miles away from the disks). Besides, I may not want to pay what RAC costs. -ER is not playing catchup with anyone I know. -The administration tool, free of charge, with plug-in capabilities and the things you can do with data collecting tasks seem to me a much better approach than AWR and ASH (here it is, use it and pay for it...) -DRDA... yes is playing catch with a standard. -RealTime loader/TimeSeries is playing catch? Doubt it... But the most features are completely customer driven features. I easily accept that some of them exist in other databases and others aren't comparable. But most important is the fact that they were put in place to solve customer issues and improve customer perceived value and experience. Most of them will only be appreciated by Informix customers. Those customers are still preferring IDS to Oracle or any other RDBMS. You probably consider them ignorants... since after all the FUD and all the features you mentioned they still prefer IDS... >> I've done "block recovery" with ontape... Just a matter of putting dd >> to work along it :). And when you need block recovery one of this >> happened: >> - You made a mistake > > Never the cause. Typical... Only SQL server DBAs make mistakes... >> - You hardware sucks > > Hard disks are hard disks. It happens. > >> - Your database has bugs > > Never the cause. > Typical... Only SQL server has bugs.... > Actually I wouldn't be. I expect 95+% of Informix shops use it. On the > Oracle side RMAN is, and has always been, free. There is no such entity > as separate licensing. onbar too... > In Oracle: > > ALTER TABLE <table_name> MODIFY (<column_name> DEFAULT <default_value>); > > Standard functionality in all products TTBOMK. We all know that... And I believe you know I knew... What I don't believe is that your explicit avoidance of the real issue is just a case of distraction... 1- I mentioned ADD a column, although the issue is probably the same 2- Do that on a table with some Million of rows... what happen? At least spare me the trouble of looking and check if they improved it in 10g or will do it in 11g... It could even be called innovation! > As does the corresponding background process in Oracle: No difference. > Anyone that claims otherwise is smoking dope. Does the background process in Oracle start whenever needed accordingly to your definition, and without any scheduling on your part? If not, give me some of that good stuff. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Fernando Nunes wrote: > DA Morgan wrote: >>> I meant it's lighter than Oracle. Uses less hardware. >> >> I didn't disagree. But my point was that the difference works out to >> about $11.25 at retail ... in other words the difference given today's >> hardware prices is inconsequential. > > Hardware is not necessarily just disk... Didn't mean to indicate that it is. But in terms of CPU and RAM the requirements are essentially identical Informix: http://www-306.ibm.com/software/data/informix/ids/requirements.html) For UNIX and Linux, we recommend a minimum of 750MB of disk space, 256MB of memory and one CPU. Oracle: http://download.oracle.com/docs/cd/B19306_01/install.102/b14312/pre_install.htm#NXCLI002 Hard disk space Total ranges from 216'738 MB Physical memory (RAM) 256 MB minimum, 512 MB recommended Processor 550 MHz minimum That extra 256MB of RAM to reach "recommended" is going to cost you how many dollars? I know you guys sincerely believe what you are writing but seriously ... both run in 256MB of RAM. Both run with a single CPU. Both require about 750MB of disk. I think you are assuming things not in evidence. >> financially inconsequential. I can't imagine made the change they did >> for the reason you list. Seems more likely it was due to their desire >> to keep it from competing with DB2 and sell as an embedded database: >> What CA did with Ingres before they through in the towel and gave it >> away. > > Any reader can choose between what I said, and what you imagine in your > dreams. Any reader can also follow the two links, above, and see that the installation requirements are essentially identical. As I said ... I know you sincerely believe there is a difference. And perhaps a decade ago that would have been true. But you can't compare 2007 versions of the products and come to the same conclusion you came to in 1987. >> $ rman target />> RMAN> backup database; >> >> can you make it simpler than that? >> >> If you did would the benefit be palpable? > > So simple it almost look like ontape :) Equally easy to use? > You're obviously ignoring the configuration steps, which could be > reduced to something similar to ontape config, but just looking at the > manual will scare many :) Here's the full configuration for RMAN. $ rman target / catalog <userid>/<password>@<catalog_database>RMAN> create catalog; RMAN> register database; If that is too much work for someone I'd suggest they find another profession or do it in the OEM GUI. > But we could talk about onstat... or not... :) The problem here are the > habits... Ontape is easy (although limited) for ages... RMAN is finally > easy... I agree. But there is no point in 2007 discussing the way things were in the previous millenium. No one is buying those old versions of either product and no one is implementing new systems in either. The question is not "where were things" but rather "where are things now." >> The question I would put to you with respect to innovation would be to >> compare the features of Cheetah, just released, with Oracle 11g, soon to >> be released. Is the innovation there or is it playing catch-up with SQL >> Server? > > -Don't know nothing about SQL server and I'm too lazy to look for... But > will 11g bring multiple active (although readonly) databases? Yes. Though here we need to take a breather to remind most that the word "database" for you means "schema" in Oracle: Completely different meanings. But truth is one could have done that for the last 15+ years in Oracle if they wanted. > Your > answer is RAC... nice... But for some purposes I really don't want all > the queries in the same disks (I even may want a server miles away from > the disks). Besides, I may not want to pay what RAC costs. Not going to argue dollars as they are what they are but these days everything is striped and mirrored on multiple disk shelves at multiple locations mirrored by multiple technologies. I haven't seen disks in years. LUNs perhaps but not disks. > But the most features are completely customer driven features. I easily > accept that some of them exist in other databases and others aren't > comparable. But most important is the fact that they were put in place > to solve customer issues and improve customer perceived value and > experience. Most of them will only be appreciated by Informix customers. That is likely true and the problem with that is that it doesn't expand the customer base. It just plays to retention which in our business is not a road that leads anywhere good. > Those customers are still preferring IDS to Oracle or any other RDBMS. Yeah but you really don't want to become the next: http://www.sapug.org > You probably consider them ignorants... since after all the FUD and all > the features you mentioned they still prefer IDS... No I don't. I'm not interested in the world of databases being one where only Microsoft and Oracle play. That doesn't achieve what I want which is a vibrant innovative marketplace. >>> I've done "block recovery" with ontape... Just a matter of putting dd >>> to work along it :). And when you need block recovery one of this >>> happened: >>> - You made a mistake >> >> Never the cause. > > Typical... Only SQL server DBAs make mistakes... Not the point ... short of using DD DBAs can not corrupt physical disk storage. >>> - Your database has bugs >> >> Never the cause. > > Typical... Only SQL server has bugs.... That wasn't the point ... of my comment. Single block recovery is almost always the result of hardware failure. >> Actually I wouldn't be. I expect 95+% of Informix shops use it. On the >> Oracle side RMAN is, and has always been, free. There is no such entity >> as separate licensing. > > onbar too... > >> In Oracle: >> >> ALTER TABLE <table_name> MODIFY (<column_name> DEFAULT <default_value>); >> >> Standard functionality in all products TTBOMK. > > We all know that... And I believe you know I knew... What I don't > believe is that your explicit avoidance of the real issue is just a case > of distraction... > 1- I mentioned ADD a column, although the issue is probably the same It is. You can do it in any major RDBMS. > 2- Do that on a table with some Million of rows... what happen? SALES1 is an empty table SALES2 has 1,000,000 rows: SQL> set timing on SQL> ALTER TABLE sales1 2 ADD (newcol NUMBER); Table altered. Elapsed: 00:00:00.04 SQL> ALTER TABLE sales2 2 ADD (newcol NUMBER); Table altered. Elapsed: 00:00:00.01 SQL> Want to see it again? SQL> ALTER TABLE sales1 2 ADD (col2 VARCHAR2(5)); Table altered. Elapsed: 00:00:00.01 SQL> SELECT COUNT(*) FROM sales1; COUNT(*) ---------- 0 Elapsed: 00:00:00.00 SQL> ALTER TABLE sales2 2 ADD (col2 VARCHAR2(5)); Table altered. E

DA Morgan wrote: > Fernando Nunes wrote: >> DA Morgan wrote: >>>> I meant it's lighter than Oracle. Uses less hardware. >>> >>> I didn't disagree. But my point was that the difference works out to >>> about $11.25 at retail ... in other words the difference given today's >>> hardware prices is inconsequential. >> >> Hardware is not necessarily just disk... > > Didn't mean to indicate that it is. But in terms of CPU and RAM the > requirements are essentially identical > > Informix: > http://www-306.ibm.com/software/data/informix/ids/requirements.html) > For UNIX and Linux, we recommend a minimum of 750MB of disk space, 256MB > of memory and one CPU. > > Oracle: > http://download.oracle.com/docs/cd/B19306_01/install.102/b14312/pre_install.htm#NXCLI002 > > Hard disk space Total ranges from 216'738 MB > Physical memory (RAM) 256 MB minimum, 512 MB recommended > Processor 550 MHz minimum > > That extra 256MB of RAM to reach "recommended" is going to cost you how > many dollars? > > I know you guys sincerely believe what you are writing but seriously ... > both run in 256MB of RAM. Both run with a single CPU. Both require about > 750MB of disk. I think you are assuming things not in evidence. This was among the less interesting stuff I've ever read from you. It's probably my bad English. Let's start for the real issue first: Real issue: What I meant was that the internal architecture of IDS makes it consume less resources *when running*. Everything is a thread, not a process, less context switching etc.... you know all this. I was NOT talking about installation required space (i talked about that below, called it footprint...). And I was NOT talking about RAM specially because the most significant part of RAM that an RDBMS consumes is for caching, and this is more or less what we want/need/can afford. Now, the FUN part :) I believe your conferences, your students, or possible the continued use of complex products is affecting your focus capability: Although I couldn't care less for announced installation requirements, I find it VERY amusing that you post here a comparison between IBM Informix Dynamic Server, and Oracle *Client* software... Wow... and Oracle uses more! LOL... I believe you were trying to post this URL: http://download.oracle.com/docs/cd/B19306_01/install.102/b15660/pre_install.htm#sthref95 Quote: " At least 1024 MB of physical RAM RAM Swap Space Between 1024 MB and 2048 MB 1.5 times the size of RAM Between 2049 MB and 8192 MB Equal to the size of RAM More than 8192 MB 0.75 times the size of RAM 400 MB of disk space in the /tmp directory Between 1.5 GB and 3.5 GB of disk space for the Oracle software, depending on the installation type 1.2 GB of disk space for a preconfigured database that uses file system storage (optional) Note: The disk space requirement for databases that use Automatic Storage Management or raw device storage is described later in this chapter. Additional disk space, either on a file system or in an Automatic Storage Management disk group, is required for the flash recovery area if you choose to configure automated backups. " No further comments except that the IDS requirements should be a little smaller for the installation space required for Cheetah (this will bring back the smile on your face hopefully, as I wrote earlier) >>> financially inconsequential. I can't imagine made the change they did >>> for the reason you list. Seems more likely it was due to their desire >>> to keep it from competing with DB2 and sell as an embedded database: >>> What CA did with Ingres before they through in the towel and gave it >>> away. >> >> Any reader can choose between what I said, and what you imagine in >> your dreams. > > Any reader can also follow the two links, above, and see that the > installation requirements are essentially identical. Any reader can now follow the real links, and not the one you post, unless the reader wants to LOL... Besides, the links point to announced requirements. They say nothing about your assumptions on why IBM did something... > As I said ... I know you sincerely believe there is a difference. And > perhaps a decade ago that would have been true. But you can't compare > 2007 versions of the products and come to the same conclusion you > came to in 1987. The differences are too obvious. And in several situations are favorable to Oracle. I said it and I repeat it: I wouldn't mind having several of Oracle (and other RDBMS) features. RAC, TAF etc. Even the ones I find less interesting like flashback... But I prefer the Cheetah improvements on what I already have. > Here's the full configuration for RMAN. > > $ rman target / catalog <userid>/<password>@<catalog_database>> RMAN> create catalog; > RMAN> register database; > > If that is too much work for someone I'd suggest they find another > profession or do it in the OEM GUI. If you want your backup files in $ORACLE_HOME/some/place... Do you? Please... If I want sand in my eyes I'll wake for January and will take a look at the Dakar rally... Much more fun that reading you... >> But will 11g bring multiple active (although readonly) databases? > > Yes. Though here we need to take a breather to remind most that the word > "database" for you means "schema" in Oracle: Completely different meanings. > Wrong again... For several reasons... Put just one database with several schemas in an instance, and it will look much more like and Oracle database... Make it an ANSI database, and again, it will be even more like one. > But truth is one could have done that for the last 15+ years in Oracle > if they wanted. Exactly the same for flashback database in Informix... The most complex part of the code is already there in the archive process. >> Your > answer is RAC... nice... But for some purposes I really don't >> want all the queries in the same disks (I even may want a server miles >> away from the disks). Besides, I may not want to pay what RAC costs. > > Not going to argue dollars as they are what they are but these days > everything is striped and mirrored on multiple disk shelves at multiple > locations mirrored by multiple technologies. I haven't seen disks in > years. LUNs perhaps but not disks. Same here... But the fact is, if you want the same data miles away (multiple copies) and still be able to read, we do it, and are improving it. >> aren't comparable. But most important is the fact that they were put >> in place to solve customer issues and improve customer perceived value >> and experience. Most of them will only be appreciated by Informix >> customers. > > That is likely true and the problem with that is that it doesn't expand > the customer base. It just plays to retention which in our business is > not a road that leads anywhere good. Check the list... there are "oracle compatibility features" also... Wonder why... > Not the point ... short of using DD DBAs can n

Fernando Nunes wrote: > Again... If I want sand in my eyes I'll prefer a trip to the desert... > Would you care to make that WITH a DEFAULT VALUE as I mentioned all > along?! If it returns immediately please tell me the version... I'll > send it to the Oracle DBAs... It doesn't and it won't. You can not visit tens of thousands of blocks instantly. But it can be done without locking. Something, alas, you've just received in Cheetah. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

DA Morgan wrote: > Fernando Nunes wrote: > >> Again... If I want sand in my eyes I'll prefer a trip to the desert... >> Would you care to make that WITH a DEFAULT VALUE as I mentioned all >> along?! If it returns immediately please tell me the version... I'll >> send it to the Oracle DBAs... > > It doesn't and it won't. You can not visit tens of thousands of blocks > instantly. But it can be done without locking. Something, alas, you've > just received in Cheetah. Ignore it as much as you want, but in IDS (not needing Cheetah) it returns immediately. As I wrote earlier, it makes an inplace ALTER. You can do something similar, because when you add a column it won't physically change or visit all the table blocks... right? With the default the same happens... why? because, if the column wasn't there, than the column value was evidently NULL and so, if you select a previous row it will return the DEFAULT. Go on... give Larry a call and ask for it, or confirm if it's in 11g... My fellow Orace DBAs would pay for it more easily than they'd pay for flashback or RAC. So, your statement should be "It doesn't IN ORACLE". I remove the part "it WON'T IN ORACLE" because i believe sometime they'll catch up. I think it's my time now to step off this thread. I'm tired of having to write 2 or 3 posts to make you admit your errors and false statements. I easily admit and don't mind to repeat here, that there are several features in other databases that I'd like to see implemented in IDS. A few of us even know I've done my best to influence their implementation. That's simply because I'd like to see more functionality on top of what I think it's a very good RDBMS. The lack of some features don't change my current opinion, and the fact that I see it being used with success in very demanding conditions, with very low maintenance (aka DBAs time). It's been nice to check some features in Oracle, and learn a bit more about it, but it's enough... If I need more I'll check the Internet... It's less tiring than pointing your mistakes. Regards. -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

DA Morgan wrote: > Fernando Nunes wrote: > >> Again... If I want sand in my eyes I'll prefer a trip to the desert... >> Would you care to make that WITH a DEFAULT VALUE as I mentioned all >> along?! If it returns immediately please tell me the version... I'll >> send it to the Oracle DBAs... > > It doesn't and it won't. You can not visit tens of thousands of blocks > instantly. But it can be done without locking. Something, alas, you've > just received in Cheetah. You don't need to. Adding a column with default is no different than one without. Because the default DEFAULT is NULL. It's just another constant. There is no need to visit anything more than the meta data. IBM has been using this "technology" since before I joined 10 years ago. (Gee.. I'm getting old). Anyway don't you guys think this thread is getting abit lengthy. You'll wreck Mark T.s beautyfull statistics and Daniel is most certainly on his path to "all time top poster" ;-) Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

Serge Rielau said: > Daniel is most certainly on his path to "all time top poster" ;-) And that would mean war ... >:o) -- Bye now, Obnoxio "I'm astonished anyone pays real money for this crap." -- Cosmo -- This message has been scanned for viruses and dangerous content by OpenProtect(http://www.openprotect.com), and is believed to be clean.

>... Anyway don't you guys think this thread is >getting abit lengthy. You'll wreck Mark T.s beautyfull statistics and >Daniel is most certainly on his path to "all time top poster" ;-) > >Cheers >Serge Amen, can we put this bloody horse under the pasture?

Fernando Nunes wrote: > DA Morgan wrote: >> Fernando Nunes wrote: >> >>> Again... If I want sand in my eyes I'll prefer a trip to the desert... >>> Would you care to make that WITH a DEFAULT VALUE as I mentioned all >>> along?! If it returns immediately please tell me the version... I'll >>> send it to the Oracle DBAs... >> >> It doesn't and it won't. You can not visit tens of thousands of blocks >> instantly. But it can be done without locking. Something, alas, you've >> just received in Cheetah. > > Ignore it as much as you want, but in IDS (not needing Cheetah) it > returns immediately. As I wrote earlier, it makes an inplace ALTER. I'll check it out. But I must confess the last time I had to do this in a production database was ... let me see ... well never. But it is interesting. Thanks for the tip. And lets kill this thread before I become a regular. ;-) -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

DA Morgan wrote: > > > I'll check it out. But I must confess the last time I had to do this in > a production database was ... let me see ... well never. But it is > interesting. Thanks for the tip. > > And lets kill this thread before I become a regular. ;-) Too Late ;-)