RE: database market share 2003

> From: Data Goob [mailto:datagoob@hotmail.com] > > In the real world Informix is already dead. > In the real world, DB2 is still in it's childhood. Some facts about DB2: 1. DB2 doesn't support table fragmentation within a single node (unlike XPS, which is able to fragment table within a single node and at the same time partition the table across nodes.) 2. DB2 still operates with 32-bit rowid's. This imposes a very hard limit (4 billion rows) on the table size. With Informix, this limit can be overcomed with intranode fragmentation. The only option with DB2 is table partitioning across cluster nodes. How many people are using inter-node partitioning for OLTP systems? 3. DB2 with it's 'no checkpoint' architecture makes very poor caching of DB writes: in DB2, only one modification is possible (from different sessions) for a page before it MUST be synced with the disk. In a real Informix/Oracle OLTP environment a page can modified many times from concurrent sessions before it goes to disk (like the 'current' page in any accumulative table) (Our typical disk write caching is >85%) 4. DB2 doesn't support implicit type casting in SQL statements and stored procedures. Can anybody imagine a headache of porting Oracle/Informix applications to DB2? 5. DB2 doesn't support defining variables in stored procedure by database column type (DEFINE my_var LIKE my_tab.my_col); 7. In it's current version, DB2 doesn't support anything like Informix HDR or Oracle's log shipping ('Stinger' is not released..) 8. DB2 terminology is totally human-unreadable. May be, this terminology came from the 'mainframe monsters' world. ------------------------------------------ Alexey Sonkin sending to informix-list

Can db2 gurus confirm/deny this:- "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message news:c9gang$675$1@news.xmission.com... > > > > > From: Data Goob [mailto:datagoob@hotmail.com] > > > > In the real world Informix is already dead. > > > > In the real world, DB2 is still in it's childhood. > > Some facts about DB2: > > 1. DB2 doesn't support table fragmentation within a single node > (unlike XPS, which is able to fragment table within a single node > and at the same time partition the table across nodes.) > > 2. DB2 still operates with 32-bit rowid's. > This imposes a very hard limit (4 billion rows) on the table size. > With Informix, this limit can be overcomed with intranode fragmentation. > The only option with DB2 is table partitioning across cluster nodes. > How many people are using inter-node partitioning for OLTP systems? > > 3. DB2 with it's 'no checkpoint' architecture makes very > poor caching of DB writes: in DB2, only one modification > is possible (from different sessions) for a page before > it MUST be synced with the disk. > In a real Informix/Oracle OLTP environment a page can modified many > times from concurrent sessions before it goes to disk (like the > 'current' page in any accumulative table) > (Our typical disk write caching is >85%) > > 4. DB2 doesn't support implicit type casting in SQL statements and stored > procedures. > Can anybody imagine a headache of porting Oracle/Informix applications to > DB2? > > 5. DB2 doesn't support defining variables in stored procedure > by database column type (DEFINE my_var LIKE my_tab.my_col); > > 7. In it's current version, DB2 doesn't support anything > like Informix HDR or Oracle's log shipping ('Stinger' is not released..) > > 8. DB2 terminology is totally human-unreadable. > May be, this terminology came from the 'mainframe monsters' world. > > > ------------------------------------------ > Alexey Sonkin > > > sending to informix-list

"Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message news:c9gang$675$1@news.xmission.com... > 8. DB2 terminology is totally human-unreadable. > May be, this terminology came from the 'mainframe monsters' world. Does DB2 run on mainframes?

"Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message news:c9gang$675$1@news.xmission.com... > > > From: Data Goob [mailto:datagoob@hotmail.com] > > > > In the real world Informix is already dead. > > > > In the real world, DB2 is still in it's childhood. > Oh Ok, that's cool, we will be excited about new features coming. > Some facts about DB2: > > 1. DB2 doesn't support table fragmentation within a single node > (unlike XPS, which is able to fragment table within a single node > and at the same time partition the table across nodes.) > I'm not sure if you understand DB2 terminology enough to comment, because it looks like your comments suggest that you misunderstand certain things about how DB2 works. Tables **can** be partitioned on a single node with one or many partitions. We ran tests on one machine, then clustered two then clustered three. The partitioning feature of DB2 is similar to co-servers on XPS, you can create virtual co-servers in DB2 just you can with XPS, on ONE server, they are called partitions, not to be confused with disk partitions. You can mix and match across nodes ( physical servers ) just like XPS. For example, we can set up a db2nodes.cfg for 3 physical machines on our 'master coserver' (although it is possible to start/stop DB2 from any physical node unlike XPS which requires the master coserver to start/stop from ): 0 server1 0 1 server1 1 2 server2 0 3 server2 1 4 server3 0 5 server3 1 The config file looks like this there is nothing else to it. The above example is the eqivalent of 2 co-servers on each machine, or known as partitions in DB2. Physically: server1 -- server2 -- server3 0 0 0 1 1 1 I could have easily just set this up on one machine or two machines, or n, it still boils down to six partitions ( six XPS co-servers ). I could have also set up 4 partitions per machine, one for each CPU. It is also important to understand this is for one instance that spans three physical machines. In Informix XPS each machine has an instance of its own, a bit more primitive in the rawest of terms of shared nothing. Here's another example, one machine, six partitions: 0 server1 0 1 server1 1 2 server1 2 3 server1 3 4 server1 4 5 server1 5 What happens next is important, the data is split up automagically for you across partitions, whether they be on one machine or 3 or 6. You define the data the way you want, and use raw-disks if you prefer or use cooked files. We're using cooked because again, I'm lazy. You can also define tables to take advantage of only certain partitions too. > 2. DB2 still operates with 32-bit rowid's. > This imposes a very hard limit (4 billion rows) on the table size. Thanks we'll stay below 4 billion rows. And probably a good idea to jump into 64-bit, and eliminate that 32-bit rowid problem. > With Informix, this limit can be overcomed with intranode fragmentation. > The only option with DB2 is table partitioning across cluster nodes. Wrong. I am not a DB2 expert but I think your understanding of DB2 is a bit off. But I also get the feeling that somehow you feel Informix is better than DB2, but one has to ask just what is it better at? What features are really missing from DB2 that we just gotta have? I already know for our purposes we won't be using anything more than the basic features. > How many people are using inter-node partitioning for OLTP systems? > I have no figures to report to you. > 3. DB2 with it's 'no checkpoint' architecture makes very > poor caching of DB writes: in DB2, only one modification > is possible (from different sessions) for a page before > it MUST be synced with the disk. > In a real Informix/Oracle OLTP environment a page can modified many > times from concurrent sessions before it goes to disk (like the > 'current' page in any accumulative table) > (Our typical disk write caching is >85%) > I don't know DB2 well enough to argue this point, but DB2 on our system is pretty darn fast, and a lot faster than SQL-Server, so fast I can't believe the difference. Guess that's all that really matters to us, and we are seeing fantastic performance with only a moderate attempt at tuning. But it does sound like DB2 has some room for improvement. We'll certainly take advantage of those improvements when they come, interesting that some of the companies we talked to using DB2 didn't seem to have any issues like this one. > 4. DB2 doesn't support implicit type casting in SQL statements and stored > procedures. Is this something we need? Or is it a reflection that you have a bad data model and need to convert data types? Converting data does not necessarily have to be done in the SQL, it can be done outside the SQL with a good ETL tool, and we have one just for that purpose. > Can anybody imagine a headache of porting Oracle/Informix applications to > DB2? > We have not tried to port any Oracle or Informix applications, but did have a pretty easy time with our SQL-Server migration, it went really smooth. Have you tried the Migration Toolkit for Oracle or Informix? The SQL-Server MTK works for us very well. > 5. DB2 doesn't support defining variables in stored procedure > by database column type (DEFINE my_var LIKE my_tab.my_col); > This feature is not available in SQL-Server either. Bummer. Guess we won't need it. Looks like an Informix feature that could show up in DB2 sometime, but it's not urgent. > 7. In it's current version, DB2 doesn't support anything > like Informix HDR or Oracle's log shipping ('Stinger' is not released..) > Is that a bad thing? Do we need that? We have replication with our SAN perhaps it makes me lazy not to mess with the database server replication. I don't like to have to work hard. We'll use the SAN, it's faster, and no DBA intervention required. > 8. DB2 terminology is totally human-unreadable. > May be, this terminology came from the 'mainframe monsters' world. > Alexey I'm sure there are other features that would be nice to see in DB2, but we're probably not gonna need 'em, and probably wouldn't know what to do with a lot of the features that are already in DB2. By the time we really get good with DB2, the Informix product line will have completely collapsed and DB2 will be there with the Informix features put into it. So we're willing to wait for those few features from Informix that are really important but not urgent. > > ------------------------------------------ > Alexey Sonkin > > sending to informix-list