Re: DB2 DOUBLES THE PERFORMANCE OF ORACLE 10G

Serge Rielau wrote: > Daniel Morgan wrote: > >> Tim Schaefer wrote: >> >>> http://www-306.ibm.com/software/data/db2/benchmarks/121503.html >>> >>> ( Gawd-I-just-love-this-shit :-) >> >> >> >> Ignoring the obvious differences in hardware making this claim >> a obvious cheap shot from a marketing department that can't put >> up a 1:1 comparison because it would have nothing to point to ... >> >> What happens when you pull the plug on one of those shared nothing >> nodes as compared to one of Oracle's shared everything nodes? What >> is the throughput? >> >> Oh yeah I remember ... shared nothing architecture has no hardware >> failures. Hardware failures only happens to the other guy. > > You throw in another 4way in standby....oh yes.. you never accepted that > proposition in the past but never explained why. Why? > > Cheers > Serge You purchase and license another full server with operating system, database software, etc. that just sits there and doesn't do anything? Well that should keep the cost down. How do you know which node will fail? -- 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, Actually you are applying Oracle licensing to your logic. What is needed is the following: HACMP which can cover 32 machines on AIX last I heard Use a SAN (just like Oracle I s'pose) to couple all amchines to all the disks 1 more box with RAM (+25% cost there given the 4 nodes there) 1 DB2 single CPU licence is needed for a failover machine (+ 1/16th cost). The one box can indeed cover all four nodes. In reality if a second node goes down you either have a software problem (in which case RAC will also go down like dominos because you run the same software on each RAC node) or you want to be far, far away...... The box and DB2 cost can be derived directly from the benchmark report. I'm no expert in SAN and HACMP but after some brainstorming consensus here is that overal cost would go up by about 10%-15%. This would still be well below the competing RAC benchmark. I think the point is that: Yes you have an idle machine. But it's total cost that counts. IBM is not required to follow Oracle's sense of aestethics and neither are customers.... Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Serge Rielau wrote: > Daniel, > > Actually you are applying Oracle licensing to your logic. Best read up on Oracle licensing ... standby machines are included at no additional cost too. I was referring to licensing and maintenance costs for all of the other components. > In reality if a second node > goes down you either have a software problem (in which case RAC will > also go down like dominos because you run the same software on each RAC > node) or you want to be far, far away...... I was thinking more along the lines of taking machines off-line due to maintenance or just the question of load-shifting. Being able to dynamically reallocate resources within the data center. > The box and DB2 cost can be derived directly from the benchmark report. > I'm no expert in SAN and HACMP but after some brainstorming consensus > here is that overal cost would go up by about 10%-15%. > This would still be well below the competing RAC benchmark. RAC is now included with standard edition licensing. So below what competing cost? Zero dollars and zero cents? > Cheers > Serge But I do have one question ... you seem to be implying that with DB2 (non mainframe) you can now put all of your database storage onto a single piece of hardware, a SAN, and share it with all nodes. If that is true you have gone from shared nothing to shared everything. When did that happen? -- 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" and Serge Rielau wrote, not in comp.databases.oracle, nor in comp.databases.ibm-db2, but in comp,databases.INFORMIX: >> Blah, blah .... DB2 this ... blah, blah .... Oracle that .... blah, blah ... DB2 that ... blah, blah, Oracle this ...... Have you tried moving your logical and physical logs into a separate dbspace?

Neil Truby wrote: > "Daniel Morgan" and Serge Rielau wrote, not in comp.databases.oracle, nor > in comp.databases.ibm-db2, but in comp,databases.INFORMIX: >>> Blah, blah .... DB2 this ... blah, blah .... Oracle that .... blah, blah > ... DB2 that ... blah, blah, Oracle this ...... > > Have you tried moving your logical and physical logs into a separate > dbspace? Or UPDATE STATISTICS? -- "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche

Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1077374551.329037@yasure>... > But I do have one question ... you seem to be implying that with > DB2 (non mainframe) you can now put all of your database storage > onto a single piece of hardware, a SAN, and share it with all > nodes. If that is true you have gone from shared nothing to > shared everything. When did that happen? This has been practiced for years, and Serge has pointed out to you before the increased blurring of shared nothing versus massive SMP approaches. But stick to the previous point you raised. Serge's post had just given you a breakdown of the additional costs for the standby node, showing them to be low even with just the 4 active nodes - and far less than the 4 node Oracle RAC solution. Your reply completely ignored that, and just restated your original premise without any explanation as to why that should still stand. Might we get a more coherent argument from one of your students? DG

Database Guy wrote: > Daniel Morgan <damorgan@x.washington.edu> wrote in message news:<1077374551.329037@yasure>... > > >>But I do have one question ... you seem to be implying that with >>DB2 (non mainframe) you can now put all of your database storage >>onto a single piece of hardware, a SAN, and share it with all >>nodes. If that is true you have gone from shared nothing to >>shared everything. When did that happen? > > > This has been practiced for years, and Serge has pointed out to you > before the increased blurring of shared nothing versus massive SMP > approaches. Sorry but that is not true. My question was rhetorical as I was trying to be kind and give a chance to correct the misdirection. > But stick to the previous point you raised. Serge's post had just > given you a breakdown of the additional costs for the standby node, > showing them to be low even with just the 4 active nodes - and far > less than the 4 node Oracle RAC solution. Your reply completely > ignored that, and just restated your original premise without any > explanation as to why that should still stand. Might we get a more > coherent argument from one of your students? > > > DG The claim that it could all be put on a SAN, while true, is obfuscation. The data must still be federated into separate storage on that shared storage device. To add or remove a node you must still bring the database down and refederate the data. What you have is a cold failover that takes many minutes, not a few seconds to restart. And even when it does restart you have to reconnect the users. It does not have anything equivalent to Oracle's shared everything where in-doubt transactions are rolled back and seemlessly restarted in a few seconds. The cold failover option is marketing spin on the same old weakness. Why not just acknowledge that shared nothing is incapable of matching the capabilities of shared everything. And that DB2 provides shared \\everything just like Oracle if you purchase the right hardware. This is not intended as a slam. Not intended to send those insecure and weak of spirit running to proclaim the return of Morgan the Wicked. It is just the nature of the underlying architecture. And is why DB2 offers shared everything on the hardware platform where it can. -- 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: > Database Guy wrote: > >> Daniel Morgan <damorgan@x.washington.edu> wrote in message >> news:<1077374551.329037@yasure>... >> >> >>>But I do have one question ... you seem to be implying that with >>>DB2 (non mainframe) you can now put all of your database storage >>>onto a single piece of hardware, a SAN, and share it with all >>>nodes. If that is true you have gone from shared nothing to >>>shared everything. When did that happen? >> >> >> This has been practiced for years, and Serge has pointed out to you >> before the increased blurring of shared nothing versus massive SMP >> approaches. > > Sorry but that is not true. My question was rhetorical as I was > trying to be kind and give a chance to correct the misdirection. Mighty white of you. -- "C'est pas parce qu'on n'a rien ' dire qu'il faut fermer sa gueule" - Coluche

Daniel Morgan wrote: > Database Guy wrote: > >> Daniel Morgan <damorgan@x.washington.edu> wrote in message >> news:<1077374551.329037@yasure>... >> >> >>> But I do have one question ... you seem to be implying that with >>> DB2 (non mainframe) you can now put all of your database storage >>> onto a single piece of hardware, a SAN, and share it with all >>> nodes. If that is true you have gone from shared nothing to >>> shared everything. When did that happen? >> >> This has been practiced for years, and Serge has pointed out to you >> before the increased blurring of shared nothing versus massive SMP >> approaches. > > Sorry but that is not true. My question was rhetorical as I was > trying to be kind and give a chance to correct the misdirection. > At any given time each node has undisputed power over it's share of the data. If a node dies for whatever reason (maintenance, failure...) then the orphaned data can get assigned to the standby node. the SAN allows the standby box to takeover another nodes job. This is done in reality. Often customer deem it _good_enough_ not to have an idle box at all. Instead they simply fail over to another node (meaning this node will have to do double work). But these are customer choices. Commonly customers run more than one logical node per box. So they would run, let's say, 16 nodes on 4 boxes. If one box goes down the 4 orphaned logical nodes would be redistributed across the remaining 3 boxes. DB2 will still run with 16 nodes, just with one less box. The load would we balanced decently enough for the time it takes to bring teh box back on line. > >> But stick to the previous point you raised. Serge's post had just >> given you a breakdown of the additional costs for the standby node, >> showing them to be low even with just the 4 active nodes - and far >> less than the 4 node Oracle RAC solution. Your reply completely >> ignored that, and just restated your original premise without any >> explanation as to why that should still stand. Might we get a more >> coherent argument from one of your students? >> >> >> DG > > > The claim that it could all be put on a SAN, while true, is > obfuscation. The data must still be federated into separate storage > on that shared storage device. To add or remove a node you must > still bring the database down and refederate the data. What you have > is a cold failover that takes many minutes, not a few seconds to > restart. And even when it does restart you have to reconnect the > users. It does not have anything equivalent to Oracle's shared > everything where in-doubt transactions are rolled back and seemlessly > restarted in a few seconds. See above. You just swap the hardware. The infrastructure of the DB2 system is unaffected. No logical node disappears, no redistribute. You have to disassociate from the notion that a node is tied to a piece of hardware and that "loosing a node" means you decrease their numbers. So we are not talking "many minutes". You are correct that this failure will require reconnect for the users connected to the node that went down. And just the same as your app needs to be able to restart a transction it can be able to restart a connection. In a DW environment reconnecting usually doesn't matter as much as in an OLTP environment. > The cold failover option is marketing spin on the same old weakness. > Why not just acknowledge that shared nothing is incapable of matching > the capabilities of shared everything. And that DB2 provides shared > everything just like Oracle if you purchase the right hardware. > > This is not intended as a slam. Not intended to send those insecure > and weak of spirit running to proclaim the return of Morgan the > Wicked. It is just the nature of the underlying architecture. And > is why DB2 offers shared everything on the hardware platform where > it can. > Daniel, who is immature? The one who acknowledges that different architectures have different advantages, or the one who says "shared nothing runs nothing". I find IBM's position a lot more mature, even in marketing. I have not heard anyone seriously stating that RAC is good for nothing. It is being regarded skeptically w.r.t. scalability. Oracle has found a nice niche in the OLTP and failover space where you need a small handfull of nodes. Shared nothing concepts (Teradata, XPS and DB2) have proven themselves for years in the datawarehousing space and hence this is where investments were made. Naturally Oracle is after the DW space and to prove RAC can scale and vice versa the competition won't stand by idly. At the end of the day the technology is secondary. It's the value proposition that counts. And if a product does not have a certain capability then this is less likely a principle problem of the technology it is more likely because someone made a business decision where to pour a few million dollars and where not. In general those making these decision have a fairly big overview and time will tell whose marketshare will increase and whose won't. As a customer and or consultant it's your job to separate the hype from the reality and decide how to get the level of service you need for the price you can afford. Whether it's 128 Node RAC or a CASIO pocket calculator must remain your choice. And the answer is not always RAC unless you got yourself brainwashed by Oracle Marketing in which case your customers will be poor and Larry can buy another yacht. I for one like Mercedes SLK, but half the year the beast won't make it up my snowed in driveway, so I don't own one.... ;-) Cheers Serge -- Serge Rielau DB2 SQL Compiler Development IBM Toronto Lab

Obnoxio The Clown wrote: > Daniel Morgan wrote: > > >>Database Guy wrote: >> >> >>>Daniel Morgan <damorgan@x.washington.edu> wrote in message >>>news:<1077374551.329037@yasure>... >>> >>> >>> >>>>But I do have one question ... you seem to be implying that with >>>>DB2 (non mainframe) you can now put all of your database storage >>>>onto a single piece of hardware, a SAN, and share it with all >>>>nodes. If that is true you have gone from shared nothing to >>>>shared everything. When did that happen? >>> >>> >>>This has been practiced for years, and Serge has pointed out to you >>>before the increased blurring of shared nothing versus massive SMP >>>approaches. >> >>Sorry but that is not true. My question was rhetorical as I was >>trying to be kind and give a chance to correct the misdirection. > > > Mighty white of you. With all the love and affection IBM is showing you guys it was the least I could do. ;-) -- 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)