Re: database market share 2003

rkusenet wrote: > http://biz.yahoo.com/rc/040526/tech_database_marketshare_1.html > > Interesting to see that database sales for windows is more than > Unix. In the industry, we've been through these statistics battles before. I wonder which variant on statistics and sample techniques they used to 'prove' this one. (Such numbers no longer mean anything except to people who have no idea what numbers mean. And for those people, I found a wonderful new book: The complete idiot's guide to statistics.) /Hans

"Hans Forbrich" <forbrich@yahoo.net> > In the industry, we've been through these statistics battles before. I > wonder which variant on statistics and sample techniques they used to > 'prove' this one. I am referring to all RDBMS sales in windows, not MS alone. The RDBMS market for 2003 was 7 billion, out of which Windows had a share of 2.79 billion. Unix was next at 2.34 billion and Linux at 299 million. I assume the rest must be in non unix proprietary operating system like that of IBM. Whichever way I look at it, it is not insignificant that Windows is at # 1 as an operating system.

> Whichever way I look at it, it is not insignificant > that Windows is at # 1 as an operating system. Its also not insignifigant that if you want to run a business with any thing akin to stability, you have to by your servers in multiples and cluster them. If everyone running Informix on Unix had to buy two (or more) of everything just to do one systems amount of work in a reliable fasion, how differnt would these numbers look? But hey, thats just my cynical opinion.

Gartner and IDC have been doing this year after year, with Gartner always publishing in May. I would assume they have methodologies that are somewhat reliable, repeatable and consistent. They never seem to quite agree, but the changes in share are a few points per year, which lends credibility. Since Gartner and IDC sell their research to customers, and earn a fair amount of money, their research might have some sort of proven track record. Hans Forbrich wrote: > rkusenet wrote: > > >>http://biz.yahoo.com/rc/040526/tech_database_marketshare_1.html >> >>Interesting to see that database sales for windows is more than >>Unix. > > > In the industry, we've been through these statistics battles before. I > wonder which variant on statistics and sample techniques they used to > 'prove' this one. > > (Such numbers no longer mean anything except to people who have no idea what > numbers mean. And for those people, I found a wonderful new book: The > complete idiot's guide to statistics.) > > /Hans

Obviously you don't understand the different clustering options available for database clustering in general. MySQL just announced shared-nothing clustering, however, it is still in its infancy. Computer Associates just announced their Ingres for Linux, and sadly seem to be following the Oracle path in terms of how they will cluster. IBM DB2 has probably the best clustering options available, and is doing the right thing in pushing into small iron compared with SQL-Server which typically requires big iron. Yukon, the upcoming release will most likely be forced to maintain some backwards compatibility simply because of the sheer volume of MS customers. Yukon is indeed the Chevy of database engines, and will have minions of slobbering Microsoft followers using it as soon as it is released or probably using the beta as production, as is so often the case with Microsoft people. We have worked with and purchased SQL-Server on big iron ( 16 CPUs ) and DB2 on small iron ( 4 CPUs ) on Linux, and have seen a profoundly positive difference in performance. The DB2 cluster smokes SQL-Server on several fronts, on 25% of the hardware resources, utilizing the same disk drives, and 10% of the cost of the 16-CPU system. This also begs the question on what is happening in MySQL, and we are taking a close look at that one too. The key is in understanding how DB2 partitioning works, and how to force parallelism with smaller servers, whether they are 32-bit or 64-bit. Big iron systems are dead, clustering is in. The closest thing Informix has is in XPS, but nobody even cares about it, and there's no knowing if XPS works well with smaller 2-CPU systems, or even 1-CPU systems. We plan on using DB2 with 4-CPU systems in the near term but for new hardware actually deploying it on 2-CPU systems. ( Ironic that Informix pushed divide-and-conquer in the '90's yet they never made XPS mainstream. ) You can also buy into the grid which is yet another distraction coming from Oracle, ( small iron still shared disk ) and not a lot of evidence to support that it even works or scales. Oracle is once again depending on market ignorance similar to Microsoft with what could be described as masquerade-clustering. It is also important to note that 'the grid' is not the same as shared-nothing sans XPS or DB2. It's more like the SETI screen saver, appropriate analogy I think. ;-) Informix people should start taking a closer look at DB2, and actually evaluate it, it will be most enlightening for you to see how DB2 partitioning works. Even though it lacks some of the bells and whistles 9.x has it would be good for you to see where the future is in database engines. The simplicity is marvelous. "sumGirl" <emebohw@netscape.net> wrote in message news:a5e13cff.0405271419.5675fde4@posting.google.com... > > Whichever way I look at it, it is not insignificant > > that Windows is at # 1 as an operating system. > > Its also not insignifigant that if you want to run a business with any > thing akin to stability, you have to by your servers in multiples and > cluster them. If everyone running Informix on Unix had to buy two (or > more) of everything just to do one systems amount of work in a > reliable fasion, how differnt would these numbers look? > > But hey, thats just my cynical opinion.

sumGirl wrote: >>Whichever way I look at it, it is not insignificant >>that Windows is at # 1 as an operating system. > > > Its also not insignifigant that if you want to run a business with any > thing akin to stability, you have to by your servers in multiples and > cluster them. If everyone running Informix on Unix had to buy two (or > more) of everything just to do one systems amount of work in a > reliable fasion, how differnt would these numbers look? > > But hey, thats just my cynical opinion. I don't think we get away that easily.... The numbers are based on $ figures, not on the number of installations. Apparently customers drop more dollars into DBMS on Windows than on any other platform. I trust that customers are well aware of TCO, so if the grand total of Wintel + DBMS of your choice + magic number in maintenance and cost of downtime is believed to be cheaper than on another box there goes. The fact that I can pick my Windows Admins of colleges by the thousands certainly helps a lot (and we likely all have Windows at home, ...) I still acn't belive (in hindsight) that no-one but Microsoft saw it coming that whatever people have at home will end up in the business sooner or later. Be it an OS, a DBMS, spreadsheet or a coffee machine. Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Data Goob wrote: > Obviously you don't understand the different clustering > options available for database clustering in general. > > MySQL just announced shared-nothing clustering, however, it > is still in its infancy. Computer Associates just announced > their Ingres for Linux, and sadly seem to be following the > Oracle path in terms of how they will cluster. > > IBM DB2 has probably the best clustering options available, > and is doing the right thing in pushing into small iron > compared with SQL-Server which typically requires big iron. I'm not sure you should be questioning other people's understanding of clustering. And if you read what I wrote ... you might note that I made no reference to clustering at all. But that said the statement: "IBM DB2 has probably the best clustering options available" only makes sense if one notes that the IBM DB2 clustering is identical to that of Oracle. If one happens to have a couple of mainframes laying around. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

"Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1085789813.699741@yasure... > Data Goob wrote: > > Obviously you don't understand the different clustering > > options available for database clustering in general. > > > > MySQL just announced shared-nothing clustering, however, it > > is still in its infancy. Computer Associates just announced > > their Ingres for Linux, and sadly seem to be following the > > Oracle path in terms of how they will cluster. > > > > IBM DB2 has probably the best clustering options available, > > and is doing the right thing in pushing into small iron > > compared with SQL-Server which typically requires big iron. > > I'm not sure you should be questioning other people's understanding > of clustering. And if you read what I wrote ... you might note that > I made no reference to clustering at all. > > But that said the statement: "IBM DB2 has probably the best clustering > options available" only makes sense if one notes that the IBM DB2 > clustering is identical to that of Oracle. If one happens to have > a couple of mainframes laying around. Data Goob is most likely referring to DB2/UDB clustering. Few days back someone told me that he is working with a 64node DB2/UDB EEE and the performance is awesome. 64 node!!!!! rk-

rkusenet wrote: > "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1085789813.699741@yasure... > >>Data Goob wrote: >> >>>Obviously you don't understand the different clustering >>>options available for database clustering in general. >>> >>>MySQL just announced shared-nothing clustering, however, it >>>is still in its infancy. Computer Associates just announced >>>their Ingres for Linux, and sadly seem to be following the >>>Oracle path in terms of how they will cluster. >>> >>>IBM DB2 has probably the best clustering options available, >>>and is doing the right thing in pushing into small iron >>>compared with SQL-Server which typically requires big iron. >> >>I'm not sure you should be questioning other people's understanding >>of clustering. And if you read what I wrote ... you might note that >>I made no reference to clustering at all. >> >>But that said the statement: "IBM DB2 has probably the best clustering >>options available" only makes sense if one notes that the IBM DB2 >>clustering is identical to that of Oracle. If one happens to have >>a couple of mainframes laying around. > > > Data Goob is most likely referring to DB2/UDB clustering. > Few days back someone told me that he is working with a 64node > DB2/UDB EEE and the performance is awesome. 64 node!!!!! > > rk- Makes sense to me. And how many CPUs per node? ;-) -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

"Daniel Morgan" <damorgan@x.washington.edu> wrote > > Data Goob is most likely referring to DB2/UDB clustering. > > Few days back someone told me that he is working with a 64node > > DB2/UDB EEE and the performance is awesome. 64 node!!!!! > > > > rk- > > Makes sense to me. And how many CPUs per node? ;-) do u think Oracle can scale above 4 nodes. Wasn't there a post in oracle newsgroup by Howard Rogers (or someone from Australia) saying that from one node to 2 there is a linear scale, after that it tapers off, and adding any nodes after 4 starts degrading the performance.

The problem is Oracles' distributed lock manager. Take note, the DLM conzept actually came from IBM, and interestingly enough, Ingres for Linux will be using it. Look at who is pushing the DLM, it's OpenDLM from IBM! http://www.eweek.com/article2/0,1759,1599317,00.asp http://oss.software.ibm.com/dlm/ http://sourceforge.net/projects/opendlm http://opendlm.sourceforge.net/ Oracle came about, if we look at history, from Larry seizing the dbms opportunity that IBM did not. So, it could be said that Oracle is a delta of DB2 on the mainframe, in its own incantation, pushed into UNIX. Incidentally, DB2 on the mainframe also uses shared-disk, invented by IBM for DB2 on the mainframe. So you can see where we're going here. Oracle is not that original of an engine when one considers its origins. Nothing wrong with the Oracle engine if you want an old, aging techology that typically requires lots of hardware, lots of CPU, and lots of people. The idea that it will perform well in the small iron space remains to be seen. Even IBM will note the unscalable aspects of shared-disk and the distributed lock manager, which must coordinate n-times the more DLMs that appear in the cluster. This is why it actually gets more complex over n-servers and cannot scale, from what we're hearing, beyond 8 servers. Shared-nothing on the other hand is not coordinating locks on the same drives so it is not concerned with distributed locks. This theory has already been proven, shared-nothing scales ad infinitum, shared-disk-dlm does not. It's not a bad thing, Oracle pushes a lot of HA sales out of their paradigm, but it is also old school, thus the grid now appears. They have to have something new to sell. But the grid is not something that has a track record in business so it really remains to be seen how it will actually fare over time. The licensing is still not cheap despite the advertising. In the meantime **today** you can get all the benefits of XPS out of DB2, in an elegantly simple construction in DB2. It is tunable for OLTP or DSS, you make the call. You can even start out without shared-nothing, no clusters at all with DB2, play with it in the same configuration as Oracle if you want to compare it, and then kick in shared-nothing, and watch the profound difference in speed as you increase partitioning and adding servers to the cluster. I can show children DB2 and get them to understand the concepts, it's really that simple. Which is why it is so perfect for our environment of SQL-Server people who are, well, children when it comes to understanding what a real database engine really is. Dare I say Informix is crude and primitive compared to DB2--Once you start taking a hard look at DB2 you will understand what I mean. "rkusenet" <rkusenet@sympatico.ca> wrote in message news:2hrobfFgkop8U1@uni-berlin.de... > "Daniel Morgan" <damorgan@x.washington.edu> wrote > > > Data Goob is most likely referring to DB2/UDB clustering. > > > Few days back someone told me that he is working with a 64node > > > DB2/UDB EEE and the performance is awesome. 64 node!!!!! > > > > > > rk- > > > > Makes sense to me. And how many CPUs per node? ;-) > > do u think Oracle can scale above 4 nodes. Wasn't there a post in > oracle newsgroup by Howard Rogers (or someone from Australia) > saying that from one node to 2 there is a linear scale, after that > it tapers off, and adding any nodes after 4 starts degrading the > performance. > >

"Data Goob" <datagoob@hotmail.com> wrote > Dare I say Informix is crude and > primitive compared to DB2--Once you start taking a hard look at DB2 you will > understand what I mean. It may very well be true, but if you want any of us to take your comments seriously, you have to reveal your identity. Do you work for IBM :-) Please do not mind. I think your contribution is much valued, but that jboss incident had made me a cynic in this regard. http://www.eweek.com/article2/0,1759,1595280,00.asp?kc=ewnws051904dtx1k0000599 cheers. ravi

Everything is up for grabs Daniel, that's what newsgroups are all about. If you understand the Informix world, you'll understand my statement, especially in the context of the Informix newsgroup. Informix people have had several servers to choose from over the years, but no one single server to adapt to different scenarios. DB2 offers probably one of the most flexible configurations I've seen, having worked with ALL vendor databases, including a significant amount of time with Sybase and even your pet Oracle. Most people do not understand the difference between the grid ( distributed computing ), shared-nothing, shared-disk, shared-everything, distributed-shared-memory, NUMA, or the various combinations of any of these, so I think it's a fair bet my statement holds water. It is not trivial to understand the differences, or make the right choices, you have to take the time to do the research. It **can** be said "IBM clustering on the mainframe is identical to Oracle clustering on UNIX" in the simplest of terms. But Oracle partitioning is different, thus the statement really cannot be made. In our particular case we couldn't care less which one is "better" from a religious context, Oracle at the business level scares the sh** out of us, and gives us pause to even talk to those people about licenses. When you also consider that on a 5-year license Oracle will be 5x what IBM is going to cost, we also have to take that into account. Not to mention that the learning curve for Oracle is a lot higher migrating from SQL-Server to Oracle than DB2, we would have to put our dunce hats on to make the Oracle choice. As I stated before, DB2 is so darn simple compared to Oracle we really don't want to have to work so hard to get things done. We would consider Sybase before Oracle in that regard, again the compatibility is right in front of us. Sybase sucks without a high-speed loader, like its bastard step-child SQL-Server, again another reason we like DB2. Oracle for all its' inherent strengths is a complete aberration to introduce into our environment, completely unnecessary, and no guarantee or knowledge base that it would work as well or as cost-effectively as DB2. I would also question your educational licensing arrangements vs. the commercial reality we live in. They are not going to hammer you with phone calls, recreational outings, enticements, etc., like they have done with us. "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1085789813.699741@yasure... > Data Goob wrote: > > Obviously you don't understand the different clustering > > options available for database clustering in general. > > > > MySQL just announced shared-nothing clustering, however, it > > is still in its infancy. Computer Associates just announced > > their Ingres for Linux, and sadly seem to be following the > > Oracle path in terms of how they will cluster. > > > > IBM DB2 has probably the best clustering options available, > > and is doing the right thing in pushing into small iron > > compared with SQL-Server which typically requires big iron. > > I'm not sure you should be questioning other people's understanding > of clustering. And if you read what I wrote ... you might note that > I made no reference to clustering at all. > > But that said the statement: "IBM DB2 has probably the best clustering > options available" only makes sense if one notes that the IBM DB2 > clustering is identical to that of Oracle. If one happens to have > a couple of mainframes laying around. > > -- > Daniel Morgan > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > damorgan@x.washington.edu > (replace 'x' with a 'u' to reply) >

I do not work for IBM, they wouldn't have me. :-) Seriously! But I do work for a highly visible company and cannot give my identity here. I can guarantee you that I do not work for IBM, or any database vendor. My comments are all based on a lot of experience, and simply going to the fine manuals, having had a lot of really great teachers to guide me. I actually fear I say too much as it is on this subject for fear of my employer spotting me. Take care, and come to your own conclusions. Install the software, and try it out. "rkusenet" <rkusenet@sympatico.ca> wrote in message news:2hrungFfu865U1@uni-berlin.de... > > "Data Goob" <datagoob@hotmail.com> wrote > > Dare I say Informix is crude and > > primitive compared to DB2--Once you start taking a hard look at DB2 you will > > understand what I mean. > > It may very well be true, but if you want any of us to take your > comments seriously, you have to reveal your identity. Do you work > for IBM :-) > Please do not mind. I think your contribution is much valued, > but that jboss incident had made me a cynic in this regard. > > http://www.eweek.com/article2/0,1759,1595280,00.asp?kc=ewnws051904dtx1k0000599 > > cheers. > > ravi > >

Data Goob wrote: > You can even start out without shared-nothing, no clusters > at all with DB2, play with it in the same configuration as Oracle if you > want to compare it, and then kick in shared-nothing, and watch the profound > difference in speed as you increase partitioning and adding servers to the > cluster. I'd caution on that statement. Shared nothing wins when the db schema is chosen wisely. One of the biggest mistakes I see when dealing with shared nothing systems is that customers define their schema and do testing on a single node and then presume they simply flip the switch and they scale lineary. Once the schema is defined properly it scales indeed very well and there are DB2 customers with > 100 nodes. It's OK to start of non-partitioned with the promise to expand later, but one should keep in mind the ultimate goal and do the design accordingly. FYI, DB2 Stinger aids the shared nothing design with a partitoning advisor. As an aside I want to comment on one common competitive statement: "IBM knows shared nothing sucks and that's why they didn't do it with DB2 z/Series" That's just wrong because of the order of events. DB2 z/Series introduced shared disc before DB2 Parallel Edition was born. A more correct statement is: "IBM realized that shared disc wouldn't suffice for the scalability requirements of BI and without hardware support (parallel sysplex), hence a different approach was chosen for DB2 on distributed platforms" That doesn't make either approach wrong, just appropriate for it's environment and it's task. Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

I agree Serge there is ground-work to be done before going shared- nothing from stand-alone SMP, and this is key. There are tables you might not want to cluster, in addition to tables you do want to cluster. You need to plan ahead and partition data and instance with deliberate planning. But it is relatively painless, the DBA can do this quite easily. The simplicity of the hierarchy is what makes it easy. Also crucial to this discussion is that DB2 at least offers a lot of flexibility in how you want to set things up, which is something I do not see in DB2 marketing. In the course of evaluating DB2 we didn't "get it" till well into the evaluation as to how DB2 performs, and how to make it perform the way it needs to, or the way we want it to. We saw the difference though once we understood the effect of instance-level partitioning. Partitioning **is** what DB2 is all about, and not just 'fragmentation' ( partitioning ) of tables to use Informix-speak. DB2 has partitioning for the instance as well as separate buffer pool management available for each database and each table, something Informix simply cannot do, as well as partitioning of the data across nodes, something only XPS can do, and only when considering a high-speed switch. DB2 has the advantage on small iron, typically 1 or 2 CPU machines when clustering, and can use a standard network environment, something Informix XPS was not really designed for. With DB2 if you prefer, use a high-speed switch and get even better performance. DB2 has the 'right' hierarchy towards instances, the rightness is in thinking that stand-alone SMP is not the highest level, but rather that clustering is the highest level. This is where you begin to see the genius in the simplicity. It becomes clear why I'm suspecting most of Informix internal folk shut up and said no more about making Informix a long-term proposition when comparing the two engines. Once you see that you can have XPS today, in a better incantation, and use one engine for OLTP or DSS, it becomes glaringly obvious why IBM is holding their ground and not pushing the "either-this-engine-or-that-engine" with Informix products. Informix products would have to add a lot of tunable parameters just to get up to the waterline of what you can do with DB2. "Serge Rielau" <srielau@ca.eye-be-em.com> wrote in message news:c9ajht$29j$1@hanover.torolab.ibm.com... > Data Goob wrote: > > > You can even start out without shared-nothing, no clusters > > at all with DB2, play with it in the same configuration as Oracle if you > > want to compare it, and then kick in shared-nothing, and watch the profound > > difference in speed as you increase partitioning and adding servers to the > > cluster. > I'd caution on that statement. Shared nothing wins when the db schema is > chosen wisely. One of the biggest mistakes I see when dealing with > shared nothing systems is that customers define their schema and do > testing on a single node and then presume they simply flip the switch > and they scale lineary. > Once the schema is defined properly it scales indeed very well and there > are DB2 customers with > 100 nodes. > It's OK to start of non-partitioned with the promise to expand later, > but one should keep in mind the ultimate goal and do the design accordingly. > FYI, DB2 Stinger aids the shared nothing design with a partitoning advisor. > > As an aside I want to comment on one common competitive statement: > "IBM knows shared nothing sucks and that's why they didn't do it with > DB2 z/Series" > That's just wrong because of the order of events. DB2 z/Series > introduced shared disc before DB2 Parallel Edition was born. > A more correct statement is: "IBM realized that shared disc wouldn't > suffice for the scalability requirements of BI and without hardware > support (parallel sysplex), hence a different approach was chosen for > DB2 on distributed platforms" > That doesn't make either approach wrong, just appropriate for it's > environment and it's task. > > Cheers > Serge > > -- > Serge Rielau > DB2 SQL Compiler Development > IBM Toronto Lab

Data Goob wrote: > I agree Serge there is ground-work to be done before going shared- > nothing from stand-alone SMP, and this is key. There are tables you > might not want to cluster, in addition to tables you do want to cluster. > You need to plan ahead and partition data and instance with deliberate > planning. But it is relatively painless, the DBA can do this quite > easily. The simplicity of the hierarchy is what makes it easy. > > Also crucial to this discussion is that DB2 at least offers a lot of > flexibility in how you want to set things up, which is something I > do not see in DB2 marketing. In the course of evaluating DB2 we > didn't "get it" till well into the evaluation as to how DB2 performs, > and how to make it perform the way it needs to, or the way we want it > to. We saw the difference though once we understood the effect of > instance-level partitioning. > > Partitioning **is** what DB2 is all about, and not just 'fragmentation' > ( partitioning ) of tables to use Informix-speak. DB2 has partitioning > for the instance as well as separate buffer pool management available for > each database and each table, something Informix simply cannot do, as well > as partitioning of the data across nodes, something only XPS can do, and only > when considering a high-speed switch. DB2 has the advantage on small iron, > typically 1 or 2 CPU machines when clustering, and can use a standard network > environment, something Informix XPS was not really designed for. With DB2 if > you prefer, use a high-speed switch and get even better performance. > > DB2 has the 'right' hierarchy towards instances, the rightness is in > thinking that stand-alone SMP is not the highest level, but rather that > clustering is the highest level. This is where you begin to see the > genius in the simplicity. It becomes clear why I'm suspecting most of > Informix internal folk shut up and said no more about making Informix a > long-term proposition when comparing the two engines. Once you see that > you can have XPS today, in a better incantation, and use one engine for OLTP > or DSS, it becomes glaringly obvious why IBM is holding their ground and not > pushing the "either-this-engine-or-that-engine" with Informix products. > Informix products would have to add a lot of tunable parameters just to get > up to the waterline of what you can do with DB2. > > > "Serge Rielau" <srielau@ca.eye-be-em.com> wrote in message news:c9ajht$29j$1@hanover.torolab.ibm.com... > >>Data Goob wrote: >> >> >>>You can even start out without shared-nothing, no clusters >>>at all with DB2, play with it in the same configuration as Oracle if you >>>want to compare it, and then kick in shared-nothing, and watch the profound >>>difference in speed as you increase partitioning and adding servers to the >>>cluster. >> >>I'd caution on that statement. Shared nothing wins when the db schema is >> chosen wisely. One of the biggest mistakes I see when dealing with >>shared nothing systems is that customers define their schema and do >>testing on a single node and then presume they simply flip the switch >>and they scale lineary. >>Once the schema is defined properly it scales indeed very well and there >>are DB2 customers with > 100 nodes. >>It's OK to start of non-partitioned with the promise to expand later, >>but one should keep in mind the ultimate goal and do the design accordingly. >>FYI, DB2 Stinger aids the shared nothing design with a partitoning advisor. >> >>As an aside I want to comment on one common competitive statement: >>"IBM knows shared nothing sucks and that's why they didn't do it with >>DB2 z/Series" >>That's just wrong because of the order of events. DB2 z/Series >>introduced shared disc before DB2 Parallel Edition was born. >>A more correct statement is: "IBM realized that shared disc wouldn't >>suffice for the scalability requirements of BI and without hardware >>support (parallel sysplex), hence a different approach was chosen for >>DB2 on distributed platforms" >>That doesn't make either approach wrong, just appropriate for it's >>environment and it's task. >> >>Cheers >>Serge >> >>-- >>Serge Rielau >>DB2 SQL Compiler Development >>IBM Toronto Lab > > > > Well, I'll waive any comments here. Neither can or want I comment on what other IBMers do or don't think/say and why, nor do I think this thread is fitting for the Informix newsgroup. Redbrick, XPS and IDS have a lot to offer to the IBM team. Crude would not be a word of my choice for any of these products. Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Serge Rielau wrote: > Data Goob wrote: > >> You can even start out without shared-nothing, no clusters >> at all with DB2, play with it in the same configuration as Oracle if you >> want to compare it, and then kick in shared-nothing, and watch the >> profound >> difference in speed as you increase partitioning and adding servers to >> the >> cluster. > > Cheers > Serge > Aren't you leaving out the part where when making the clustering decision with shared nothing you have to create separate databases, for each node, well except on mainframes, whereas with shared-everything no change to the storage need be made. Nodes can be dynamically added or removed from the cluster real-time. I would think that a major consideration. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

Your comments are interesting, and somewhat accurate when talking about SQL-Server clustering, which is an abomination and true cluster f*** waiting to happen. With SQL-Server, you have to create duplicate databases and tables on each node, naming them slightly different names and you pretty much have to manage data skew on your own. Little if any parallelism or the ability to manage it is available. We have not heard of anyone actually doing SQL-Server clustering, although it is supposedly possible. Not to mention there is practically no control over logical logs with SQL-Server. It is total crap, a toy by comparison with DB2 or Oracle or Informix. As far as DB2, the database is created across partitions and nodes. "Daniel Morgan" <damorgan@x.washington.edu> wrote in message news:1085885187.582683@yasure... > Serge Rielau wrote: > > Data Goob wrote: > > > >> You can even start out without shared-nothing, no clusters > >> at all with DB2, play with it in the same configuration as Oracle if you > >> want to compare it, and then kick in shared-nothing, and watch the > >> profound > >> difference in speed as you increase partitioning and adding servers to > >> the > >> cluster. > > > > Cheers > > Serge > > > > Aren't you leaving out the part where when making the clustering > decision with shared nothing you have to create separate databases, > for each node, well except on mainframes, whereas with shared-everything > no change to the storage need be made. Nodes can be dynamically added or > removed from the cluster real-time. > > I would think that a major consideration. > -- > Daniel Morgan > http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp > http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp > damorgan@x.washington.edu > (replace 'x' with a 'u' to reply) >

Data Goob wrote: > Your comments are interesting, and somewhat accurate when talking about > SQL-Server clustering, which is an abomination and true cluster f*** > waiting to happen. With SQL-Server, you have to create duplicate > databases and tables on each node, naming them slightly different names > and you pretty much have to manage data skew on your own. Little if any > parallelism or the ability to manage it is available. We have not heard > of anyone actually doing SQL-Server clustering, although it is supposedly > possible. Not to mention there is practically no control over logical logs > with SQL-Server. It is total crap, a toy by comparison with DB2 or Oracle > or Informix. As far as DB2, the database is created across partitions and nodes. My understanding is the same as yours. Microsoft's so-called clusters are really just fail-over and their so-called four node cluster has yet, AFAIK, been implemented by anyone. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

"Serge Rielau" <srielau@ca.eye-be-em.com> wrote in message news:c9ajht$29j$1@hanover.torolab.ibm.com... > Data Goob wrote: > > > You can even start out without shared-nothing, no clusters > > at all with DB2, play with it in the same configuration as Oracle if you > > want to compare it, and then kick in shared-nothing, and watch the profound > > difference in speed as you increase partitioning and adding servers to the > > cluster. > I'd caution on that statement. Shared nothing wins when the db schema is > chosen wisely. One of the biggest mistakes I see when dealing with > shared nothing systems is that customers define their schema and do > testing on a single node and then presume they simply flip the switch > and they scale lineary. > Once the schema is defined properly it scales indeed very well and there > are DB2 customers with > 100 nodes. > It's OK to start of non-partitioned with the promise to expand later, > but one should keep in mind the ultimate goal and do the design accordingly. > FYI, DB2 Stinger aids the shared nothing design with a partitoning advisor. > > As an aside I want to comment on one common competitive statement: > "IBM knows shared nothing sucks and that's why they didn't do it with > DB2 z/Series" > That's just wrong because of the order of events. DB2 z/Series > introduced shared disc before DB2 Parallel Edition was born. > A more correct statement is: "IBM realized that shared disc wouldn't > suffice for the scalability requirements of BI and without hardware > support (parallel sysplex), hence a different approach was chosen for > DB2 on distributed platforms" > That doesn't make either approach wrong, just appropriate for it's > environment and it's task. Can you post your $ONCONFIG file and output from onstat -p?

Until you have actually sat in the chair as a DBA on ALL Informix products, and as a DBA using DB2 could you comment, so that is why I would invite other IBM people besides yourself to comment. To say that it is not appropriate for Informix people is to deny that Informix products are a product line OWNED BY IBM. Informix is not an independent company, it IS IBM. There is no offense talking about DB2 features here in Informix, don't worry people will probably like to know. While the upgrades to Informix products are noble, they **will** eventually be absorbed into DB2, so the conversation is not lost on this audience. If I were an Informix DBA I would be extremely interested in knowing what DB2 has that Informix does not and the reverse. Since I've taken the time to work with both products I can tell you the differences. What DB2 really lacks are good docs showing the comparisons, something IBM should provide Informix people, and just get on with it. It should not have to come from the end-user community, it should come from IBM, and allow people to get excited about it enough to let go of Informix products. I have yet to see anything missing in DB2 that is present in Informix that we just had to have or that we could not live without. Both products excel at simplicity and tunability, common ground for both communities. PS Andrew Hamm I was wondering where my laugh-for-today was going to come from. ;-) "Serge Rielau" <srielau@ca.eye-be-em.com> wrote in message news:c9bfeo$41s$1@hanover.torolab.ibm.com... > Well, I'll waive any comments here. > Neither can or want I comment on what other IBMers do or don't think/say > and why, nor do I think this thread is fitting for the Informix newsgroup. > Redbrick, XPS and IDS have a lot to offer to the IBM team. Crude would > not be a word of my choice for any of these products. > > Cheers > Serge > -- > Serge Rielau > DB2 SQL Compiler Development > IBM Toronto Lab

Data Goob wrote: > What DB2 really lacks are good docs showing the comparisons, something > IBM should provide Informix people, and just get on with it. It should > not have to come from the end-user community, it should come from IBM, I would like to respectfully disagree. It should come from the user community. And, as you state, from persons that have wide experience with both product lines. Anything that comes from IBM will be written with marketing's heavy hand involved in the editing. What comes from DBAs and developers can contain a lot more unvarnished, and untarnished, truths. -- Daniel Morgan http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp damorgan@x.washington.edu (replace 'x' with a 'u' to reply)

Daniel Morgan wrote: > Aren't you leaving out the part where when making the clustering > decision with shared nothing you have to create separate databases, > for each node, well except on mainframes, whereas with shared-everything > no change to the storage need be made. If I would have said that it would have been a lie. If you say that it's ignorance (or a lie - We'll never know...). A DB2 sytem running with database partitioning is 1(one, uno, une, eine, adjien) database, create with a simple command: CREATE DB <dbname>. Every table is created using 1 create table statement. No explicit partition names, views or whatever. You insert, update, delete, select, import and load 1 table. Oh and: There are no frigging 2-Phase-Commits the application has to worry about either no matter how often Oracle repeats the garbage! What about putting down the Oracle marketing material for a seocnd and getting yourself a DB2 book before yacking about stuff you have no clue about? > Nodes can be dynamically added or > removed from the cluster real-time. Ahh, now we're talking. You can add a node fairly easily actually. It's up to you whether you just want to get the CPU horsepower or actually repartition the data, which you can do over time. The capability of doing that online has nothing to do with shared nothing, but everything with what customers need. In a BI environment it is simply more important to reach those 100s of nodes at all than doing online repartitioning. One makes thy choices. Blame DB2 V8 for not doing it, fair enough. But don't blame shared nothing. It's absolutely doable. > I would think that a major consideration. Depending on the customer, sure, - as are many other things like will it actually get linearly faster if I double my nodes from 64 to 128. Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab