Comments on: Oracle’s hardware strategy http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/ Choices in data management and analysis Thu, 09 Feb 2012 09:22:14 +0000 hourly 1 http://wordpress.org/?v=3.0.3 By: Ritu Patial http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-126807 Ritu Patial Wed, 24 Jun 2009 10:56:58 +0000 http://www.dbms2.com/?p=774#comment-126807 hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii hiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiiii

]]> By: Peter http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-122279 Peter Thu, 21 May 2009 05:44:54 +0000 http://www.dbms2.com/?p=774#comment-122279 Yet another spin: http://www.marketwatch.com/story/despite-promises-oracle-may-sell-off-sun-hardware Peter Yet another spin:

http://www.marketwatch.com/story/despite-promises-oracle-may-sell-off-sun-hardware

Peter

]]> By: Curt Monash http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-121262 Curt Monash Wed, 13 May 2009 04:00:38 +0000 http://www.dbms2.com/?p=774#comment-121262 Robert, Back in the 1980s, Oracle used to say that it's IBM mainframe port was 2 years away. This lasted long enough that I started calling that figure "Larry Ellison's constant." Then one day I called his office, and asked his assistant Jenny Overstreet how the mainframe port was coming. She said "Let me put it this way; I'm sitting here reading an MVS manual." That told me a lot about her as well as about product delivery dates ... ... but I agree that Oracle never was, is not, and never will be a serious contender on IBM mainframes. CAM Robert,

Back in the 1980s, Oracle used to say that it’s IBM mainframe port was 2 years away. This lasted long enough that I started calling that figure “Larry Ellison’s constant.” Then one day I called his office, and asked his assistant Jenny Overstreet how the mainframe port was coming. She said “Let me put it this way; I’m sitting here reading an MVS manual.” That told me a lot about her as well as about product delivery dates …

… but I agree that Oracle never was, is not, and never will be a serious contender on IBM mainframes.

CAM

]]> By: Robert Young http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-121260 Robert Young Wed, 13 May 2009 03:15:07 +0000 http://www.dbms2.com/?p=774#comment-121260 >> there aren’t at IBM, whose recent mainframe custom-processor offerings seem to do more as gimmicks to reduce software licensing cost than they do as genuine performance accelerators Last I checked, the z/Series processor had hardware BCD, and was alone as such. BCD is critical to COBOL code, which still exists and procreates by the millions each year. z/OS DB2 depends on this datatype and language; the relationship between z/OS DB2 and z/Series machines is either symbiotic or co-dependent, as your worldview determines. According to legend, Oracle is a mangy dog on z/Series. Whether Oracle can spin SPARC machines, however massive, with Solaris as replacements for COBOL-z/OS-RACF-auditing-blah is questionable. About as likely as Rush planting a big juicy one on Michelle. My experience tells me that z/OS DB2 is mostly COBOL retro-fits, and Oracle doesn't have any chance to move SPARC/Oracle machines there. Larry's delusional if he really thinks that getting Sun will enable him to displace existing applications written to DB2-z/Series. >> I’d guess IBM gets a lot of the hardware revenue underneath DB2 If you're referring to z/Series, I saw it the opposite: IBM moves dinosaur COBOL/VSAM code to "DB2" in order for clients to be able to PowerPoint that ABC application (first written in 1975, and maintained since) is now a "database application" because it now runs on DB2. Little to none of the RDBMS facilities are used. In other words, there's no opportunity for SPARC/Oracle here. The folks who make applications for z/Series (not running the Linux emulation) are COBOL-ers to the death. >> there aren’t at IBM, whose recent mainframe custom-processor offerings seem to do more as gimmicks to reduce software licensing cost than they do as genuine performance accelerators

Last I checked, the z/Series processor had hardware BCD, and was alone as such. BCD is critical to COBOL code, which still exists and procreates by the millions each year. z/OS DB2 depends on this datatype and language; the relationship between z/OS DB2 and z/Series machines is either symbiotic or co-dependent, as your worldview determines. According to legend, Oracle is a mangy dog on z/Series.

Whether Oracle can spin SPARC machines, however massive, with Solaris as replacements for COBOL-z/OS-RACF-auditing-blah is questionable. About as likely as Rush planting a big juicy one on Michelle. My experience tells me that z/OS DB2 is mostly COBOL retro-fits, and Oracle doesn’t have any chance to move SPARC/Oracle machines there.

Larry’s delusional if he really thinks that getting Sun will enable him to displace existing applications written to DB2-z/Series.

>> I’d guess IBM gets a lot of the hardware revenue underneath DB2

If you’re referring to z/Series, I saw it the opposite: IBM moves dinosaur COBOL/VSAM code to “DB2″ in order for clients to be able to PowerPoint that ABC application (first written in 1975, and maintained since) is now a “database application” because it now runs on DB2. Little to none of the RDBMS facilities are used. In other words, there’s no opportunity for SPARC/Oracle here. The folks who make applications for z/Series (not running the Linux emulation) are COBOL-ers to the death.

]]> By: Curt Monash http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-120726 Curt Monash Sat, 09 May 2009 20:41:38 +0000 http://www.dbms2.com/?p=774#comment-120726 Jeff, I don't think MySQL's current helpful but otherwise hands-off approach is a good long-term match for Oracle's approach to things. Hence my multiple blog posts on related subjects. CAM Jeff,

I don’t think MySQL’s current helpful but otherwise hands-off approach is a good long-term match for Oracle’s approach to things.

Hence my multiple blog posts on related subjects.

CAM

]]> By: Jeff http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-120713 Jeff Sat, 09 May 2009 14:35:30 +0000 http://www.dbms2.com/?p=774#comment-120713 What will Oracle do with Sun's storage engine partner strategy? What will Oracle do with Sun’s storage engine partner strategy?

]]> By: Peter http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-120602 Peter Fri, 08 May 2009 19:29:25 +0000 http://www.dbms2.com/?p=774#comment-120602 What's interesting is that for a long time Oracle favored the grid strategy - many small boxes rather than big systems. He points out Fujitsu as partner for SPARC. So that seems to me a shift in strategy as Fujitsu's focus is on big boxes (SUN's M systems). Also he doesn't mention SUN's own SPARC development efforts the T series. Not sure if this means anything. As for MySQL - it could be that they use MySQL for the the SMB market. It might be feasable to run MySQL and Oracle DB as 2 very distinct products - kinda like Access and SQL server. (I am guessing here - of course) What’s interesting is that for a long time Oracle favored the grid strategy – many small boxes rather than big systems. He points out Fujitsu as partner for SPARC. So that seems to me a shift in strategy as Fujitsu’s focus is on big boxes (SUN’s M systems). Also he doesn’t mention SUN’s own SPARC development efforts the T series. Not sure if this means anything.

As for MySQL – it could be that they use MySQL for the the SMB market. It might be feasable to run MySQL and Oracle DB as 2 very distinct products – kinda like Access and SQL server. (I am guessing here – of course)

]]> By: barney finucane http://www.dbms2.com/2009/05/08/oracles-hardware-strategy/#comment-120547 barney finucane Fri, 08 May 2009 12:14:50 +0000 http://www.dbms2.com/?p=774#comment-120547 Oracle has several internal inefficiencies in its database to insure cross platform compatibility. One good example is the inherently non-native base 100 format of the numbers it stores. Maybe they'll build a chip to deal with that. Oracle has several internal inefficiencies in its database to insure cross platform compatibility. One good example is the inherently non-native base 100 format of the numbers it stores.

Maybe they’ll build a chip to deal with that.

]]>