Re: No future for DB2
DA Morgan wrote: > Buck Nuggets wrote: >> db2 has less moving parts to worry about > Oracle has one ... RMAN ... how many less does DB2 have? Hmm, most databases I've worked with don't require an entire subsystem to make restoration humanly possible. Granted - oracle gives a vast variety of restoration options, still - most databases don't need entire manuals on just backup & recovery: just a single chapter in a book. A chapter that a junior dba can easily master, and can be expected to perform correctly in a pinch. And rman doesn't insulate the dba from all of the complexity of error stacks, scns, resetlog/incomplete recovery complexities, etc. Nor does a GUI & responsitory-based approach beat a simple text backup command without bringing up a variety of other challenges. In the management of remote databases over various line speeds, GUIs leave a lot to be desired. In the reliable and mature management of any software, the ideal process involves the use software configuration management practices & tools (cvs, etc), testing of the process in a test environment and checkout to production. Not, a manual reentry of data into a production repository. So yeah, RMAN is great, and I won't hesitate to use it on my next oracle project. But it's only great compared to the oracle alternatives. Which is a problem that appears peculiar to oracle.
Buck Nuggets wrote: > Hmm, most databases I've worked with don't require an entire subsystem > to make restoration humanly possible. Granted - oracle gives a vast > variety of restoration options, still - most databases don't need > entire manuals on just backup & recovery: just a single chapter in a > book. A chapter that a junior dba can easily master, and can be > expected to perform correctly in a pinch. Very good point, in fact. One might of course also deduct that most other databases gloss over the multiple possibilities and combinations of recovery. One size fits all comes to mind. With the obvious consequences in downtimes. Having said that, I'm the first to agree: Oracle recovery is a tad too far optioned and it can be very confusing. I'd like to see a much simpler approach for the Standard Edition of the software and yes of course, a "full blown all bells and whistles" for the Enterprise Edition. > oracle project. But it's only great compared to the oracle > alternatives. Which is a problem that appears peculiar to oracle. I assume you mean "the alternatives within oracle"? ;) Well, having been on the receiving end of recovering SS and udb databases in Windoze, all I can say is without RMAN I don't see Oracle as that much different from the others: "Cleanup remnants, restore from backup, restart in maintenance mode, apply logs, reopen for general access." Exactly what is soooo complex about that? Or soooo diferent from what everyone does? Ah!: you mean what to do if you do NOT want to wait for a complete restore of ALL database files? Well, asking how to do that in udb and SS would be a good starting point. Instead of blaming Oracle for being able to, with/without RMAN...
Buck Nuggets wrote: > DA Morgan wrote: > > >>Buck Nuggets wrote: >> >>>db2 has less moving parts to worry about > > >>Oracle has one ... RMAN ... how many less does DB2 have? > > > Hmm, most databases I've worked with don't require an entire subsystem > to make restoration humanly possible. Granted - oracle gives a vast > variety of restoration options, still - most databases don't need > entire manuals on just backup & recovery: just a single chapter in a > book. A chapter that a junior dba can easily master, and can be > expected to perform correctly in a pinch. On the other hand RMAN allows almost instantaneous replacement of a single damaged block in a multi-terabyte datafile. You can hav a choice ... you can have simple and be off-line for hours ... or you can have a tool included in your license that gets you back on-line before the CTO can call to complain. Anyone incapable of using RMAN shouldn't be allowed to touch a keyboard or to operate a radio. -- Daniel A. Morgan http://www.psoug.org damorgan@x.washington.edu (replace x with u to respond)