RE: database market share 2003

Goob, First, some more facts about DB2: 1. In DB2, the location of table indexes MUST be specified at table creation. It's impossible to 'create index in....'. Very unflexible 2. DB2 installes into a fixed location on a hard drive. This directory can't be 're-linked', because DB2 installer ceated a lot of links to that location. This has a severe effect on DB2 upgrades. To switch the system from one DB2 version to another, it is necessary first to stop DB2, then completely remove old software, install new software into the same location and only then start DB2. It takes few seconds to one minute with Informix to upgrade from one version to another (in terms of system downtime), and takes up to 30 minutes to do it with DB2. Is DB2 a database for 24x7 systems? 3. Cross-database queries within a single DB2 instance do not perform as though they are local queries (like in Informix). This will be a shock to those why normally have different databases for loosely related applications with Informix and makes occasional inter-database queries... See other comments below > -----Original Message----- > From: Data Goob [mailto:datagoob@hotmail.com] > > "Alexey Sonkin" <alexeis@grandvirtual.com> wrote in message > > > > > 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. > What You say is that one can easily simulate a cluster on a single machine - that is, run several DB2 instances on a single machine. Not a big deal. Many XPS customers were doing the same when they were running 32-bit version of XPS (when 64-bit XPS was not available) on the monstrous 64-bit SMP hardware. What I say is that XPS support HYBRID fragmentation. Table can be fragmented on a single node (vertical fragmentation) by hash and at the same time fragmented by expression across XPS co-servers (instances in DB2 terminology) - horizontal fragmentation. > > 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. Are You sure, that 64-bit DB2 is using 64-bit ROWID? I think, You are wrong on that > > With Informix, this limit can be overcomed with intranode fragmentation. > > The only option with DB2 is table partitioning across cluster nodes. > > Wrong. I can just repeat, that there is no intra-instance table fragmentation in DB2. I'm pretty sure I'm not wrong on that > 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. Did You ever deal with LARGE systems? > > How many people are using inter-node partitioning for OLTP systems? > > I have no figures to report to you. Share-nothing architecture is good for DataWarehousing, not for OLTP. > > 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. I believe, that DB2 is very fast in reporting, in index creation... I'm talking about OLTP insert performance from parallel sessions into a single table. > > > > 4. DB2 doesn't support implicit type casting in SQL statements and > > stored procedures. > > Is this something we need? O