Re: No future for DB2
Posted in 2005
Not a technical support thread but an opinion/flame debate (cross-posted among database groups) about an article predicting "no future for DB2". Participants argue over mainframe vs. commodity hardware economics, cost of training staff in COBOL/CICS/z/OS skills, and whether DB2 is easier to learn and administer than Oracle, with side arguments about Oracle RMAN/OEM backup being simple versus adequate for real recovery scenarios. Mark A also complains that the discussion confuses DB2 for Linux/UNIX/Windows with DB2 for z/OS. No technical problem is solved and no conclusion is reached.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Server Administration
"DA Morgan" <damorgan@psoug.org> wrote in message news:1122536353.139043@yasure... > > Even if your statements are correct I don't believe it is going to > happen that way. > > Lets say I have DB2 in my facility ... I was at a major IBM shop in > Portland Oregon three weeks ago that is precisely that. > > And lets say the CTO isn't a software bigot but rather has his > corporation's best interests at heart. The CTO has a choice ... hire > young inexperienced talent and train them up to the level of those of > us in our 50s and 60s on mainframes which means also teaching COBOL, CICS, > MVS JCL, OS/390, z/OS, TSO, VSAM, IMS, REXX, ISPF, and CLISTS > or get already trained talent straight out of a college program. > > Lets say the CFO of the firm has a choice of maintaining big iron > with attendant costs in infrastructure including power conditioning, > air conditioning, etc. or can build a mainframe from 2 proc or 4 proc > commodity hardware for a fraction of the cost and get the same > computing power at a fraction of the cost. Look at the number of > super computers now build from commodity hardware for example. > > And lets say the Board of Directors is paying attention to the fact > that reducing costs increases the value per share of the stock which > is their fiduciary responsibility to the stockholders the direction > is clear. > > The number of DBAs required in the future is going down like the > value of Sun Microsystems stock. > > So yes there will be holes in the organization created. But I've yet > to meet the CTO whose solution was to incur the cost of training on > mainframe technologies. Heck most won't even pay money to train their > existing staff and they too need it. > > It is all about dollars. > The C-Level management is looking out for the bottom line. > We need to be look out for our mortgage payments. > -- > Daniel A. Morgan You seem to be talking about DB2 for Linux, UNIX, and Windows (LUW) and DB2 for z/OS as if they are one product and confusing the entire issue we are discussing. Secondly, DB2 on both the mainframe and LUW is far easier to learn and administer than Oracle, at least for now. As Oracle gets easier to use, the number of people required to administer it (DBA's) will decrease.
> > You seem to be talking about DB2 for Linux, UNIX, and Windows (LUW) and > DB2 for z/OS as if they are one product and confusing the entire issue we > are discussing. > > Secondly, DB2 on both the mainframe and LUW is far easier to learn and > administer than Oracle, at least for now. As Oracle gets easier to use, > the number of people required to administer it (DBA's) will decrease. > I have been working with both Oracle and DB2. I don't find DB2 to be any easier to learn than Oracle, especially DB2 on z.
> I don't find DB2 to be any easier to learn than Oracle There are corners of the product that can be a little more complex - perhaps locking sometimes, plans and static sql if you decide to use it. On the flip side there are areas that are much easier. The glaring one is backup & restore, that's a critical activity that's a piece of cake compared to oracle. Over the last year two folks on my team received their db2 certification. Shockingly, they weren't in the 50s, these guys are in the mid-twenties. We worked together every thursday at lunch, went through the cert book, and both passed easily. These guys learned easily, on the job, with *zero* formal training. One of them is now the development and production dba for a very large data warehouse and set of marts. Knows the hardware, os, database configuration and tunings, optimizes the user's sql, designs new tables, create the etl as well as aggregation code, etc. Prior to twelve months ago he had never seen a database beyond submission of sql, now we're partnering on taking this real-time warehouse to high-availability. Oh yeah, and he also supported a critical oltp database as well. In my opinion db2 is pretty easy to learn - it would have been far more difficult to get these guys to the same point in Oracle. On the flip side, SQL Server, MySQL, and Postgresql would have been even easier than DB2 - but then again their scalability limitations (parallelism/partitioning/optimizer/etc) would have pushed so much extra complexity into the design it probably would have been tougher after all.
Mark A wrote: > You seem to be talking about DB2 for Linux, UNIX, and Windows (LUW) and DB2 > for z/OS as if they are one product and confusing the entire issue we are > discussing. So now they are separate products? Either way ... I don't recall making a single reference to Linux, UNIX, or Windows. Perhaps my reference to COBOL, CICS, MVS JCL, OS/390, z/OS, TSO, VSAM, IMS, REXX, ISPF, and CLISTS confused you. z/OS runs on Windows now? Didn't realize how far out of the loop I was. ;-) -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)
Buck Nuggets wrote: >>I don't find DB2 to be any easier to learn than Oracle > > > There are corners of the product that can be a little more complex - > perhaps locking sometimes, plans and static sql if you decide to use > it. On the flip side there are areas that are much easier. The > glaring one is backup & restore, that's a critical activity that's a > piece of cake compared to oracle. In Oracle back-up takes two mouse clicks ... how complex is that? Better take a look at 9i and 10g RMAN and the easy setup using OEM and the Grid Control. I think your experience with Oracle is dated. -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)
DA Morgan wrote: > In Oracle back-up takes two mouse clicks ... how complex is that? > Better take a look at 9i and 10g RMAN and the easy setup using OEM and > the Grid Control. I think your experience with Oracle is dated. Yep, it's a year old. Last year I was supporting a mission-critical 300 gbyte oracle 9i database running over 100,000 transactions a day. Personally, I'd like to be prepared for something besides a 'best-case recovery scenario'. Two mouse-clicks? Please, save that for kids in database 101 who don't know any better. buck
"DA Morgan" <damorgan@psoug.org> wrote in message news:1122600962.204347@yasure... > Mark A wrote: > >> You seem to be talking about DB2 for Linux, UNIX, and Windows (LUW) and >> DB2 for z/OS as if they are one product and confusing the entire issue we >> are discussing. > > So now they are separate products? > > Either way ... I don't recall making a single reference to Linux, UNIX, > or Windows. Perhaps my reference to COBOL, CICS, MVS JCL, OS/390, z/OS, > TSO, VSAM, IMS, REXX, ISPF, and CLISTS confused you. > > z/OS runs on Windows now? Didn't realize how far out of the loop I was. > ;-) > > -- > Daniel A. Morgan There article in question (remember the article?) was predicting the future of DB2 for LUW, not DB2 for z/OS. Yes they are separate products, but they are reasonably close at the DML level. The fact that you didn't make any reference to DB2 for LUW and the article focused on that product, is the basic problem with your analysis.