The main reason that multi-threaded programming is the in thing is that process creation on Windows is many times slower than thread creation. You can see this if you compare the performance of a complex shell script on Unix vs. Windows. See also Apache 1 vs Apache 2.
Right now C (and other iterative languages) are starting to look like assembler was in the 50s and 60s, lots of people insisting that the only way to get decent performance was to program at the lowest level possible. As the number of cores increases we're going to have to accept that the shared-nothing approach of functional style languages will be better suited to exploit these resources, even if they are slower on smaller scale SMP systems.
1. The SMS only happens if you actually try to do a transaction. 2. The SMS also supplies destination account and amount.
So MIM would only work iff they intercepted an attempt by me to make a payment, and I didn't check the details in the SMS. If I get a transfer SMS out of the blue then I know something's up.
If I lose my mobile then I do what our stone-age ancestors did, and actually go to the physical bank building and fill out a transfer request.
If I make regular payments to a particular account I can also preset the details and avoid the SMS procedure. Requires some paperwork at the bank, though, so they can verify my identity then.
My bank sends me an SMS with a one-time password every time I do a transaction online. You have to type in the password on the web page to confirm the transaction.
The Design Museum in London has a whole section devoted to the presentation of information and the way bias can be introduced depending on the method selected.
They have everything from pie-charts prepared by Florence Nightingale comparing the death rates in battle vs. the field hospitals to a graphical representation of the Linux Kernel.
A friend of mine went through the driver's window of a car that turned while he was overtaking. His shoulder hit the A-pillar. Fortunately his (cordura) jacket had good armour and all he suffered was a bruised shoulder. The car was written off.
I have a RiDE magazine comparison of bike gear through the ages - armour has really improved over the past 5 years.
Dunno - not much 'deep' knowledge about Windows is transferable to Linux, since they are fundamentally quite different.
If you really want to get under the covers then some basic tips:
o It's all about files - that's the single concept that drives pretty much everything. Your initialisation, configuration, hardware devices and system state can all be found in the file system. So learn the FS layout and how to navigate around with ease - commands like find, grep, locate, mount. Know what is found in/etc,/dev,/proc and so on. I've solved many configuration mysteries by simply grepping through/etc
o I use gentoo, but not the livecd, so I don't know much about the hardware config stuff. However, Knoppix has excellent hardware detection, so it's often worth booting a Knoppix cd and using lsmod to see what modules (drivers) it's loaded.
o If you're going to try something like gentoo or one of the other minimalist distributions, the best thing to do is take it slowly - don't worry about setting it up for all your hardware, just the basics (keyboard, mouse, CPU, etc). If your hardware isn't too unusual then a vanilla kernel (with no config changes) should probably work. Once you've got it up and running you can easily go back and add support for stuff like sound cards in the kernel configuration. If you get stuck use grep and find on the kernel source files to look for info about your hardware to help figure out what options you'll need. The file/proc/pci contains details of the hardware attached to your pci bus.
"Fat" distros like RH, Mandrake, Suse avoid this by compiling support for all hardware and using a program to decide what drivers to load at boot.
X doesn't need as much configuration as it used to but if you have problems try xorgcfg.
How often do I use the silly top speed of my bike? Never.
How often do I use it's incredible cornering ability? Never - if there's a bend in the road it's usually going 'round something I can't see through, don't want to hit a truck or something.
How often do I get to use it's crazy acceleration? Every time I pull up alongside a Porsche, Ferrari, or BMW M-car at the lights. Which isn't very often, because they're usually stuck back in the queue behind a Toyota. Splitting lanes means I get to be at the front of pretty much every red light, so there's always an open road in front.
We've been running DB2 on Linux for nearly 4 years now - it works fine on our quad Xeon box. At first I had a few problems sorting out the weird Mainframe jargon IBM uses for configuration, but once I got it running it hasn't really given any problems.
DBs aren't very big - data for dynamic web pages at 2Gb, and a warehouse at 4Gb.
I'm not a DBA, and it's so low maintenance that really I know very little about it at all, it takes care of itself.
Certainly works better than the SQL Server we have of equivalent vintage, which seems to have a problem scheduling queries - one big query brings the whole system to a crawl. On the DB2 server a big query increases latency slightly, but that's about all you notice.
That's funny - I have here a box running Redhat 7.1 that provides a public share and a PDF printing service, both accessed almost exclusively from Windows NT 4.0 desktop machines. I certainly haven't created Linux accounts for the 200-odd users on the network.
As others have said, compilers can get close enough to a human's performance to make hand coded assembly unnecessary. Other advantages the compiler has include:
o Support for different variations of an architecture. e.g. your carefully tuned 386 code doesn't perform as well as it could on a Pentium.
o Ability to optimize different cases (code size vs. performance) at the flip of a switch.
o You can take advantage of advances in optimization technology. e.g. gcc 3.2 vs 2.95. Hand optimized code can never get any better without human intervention.
As Knuth said, premature optimization is the root of all evil.
I used Tom's Root Boot (http://www.toms.net/rb/). As long as you can get the networking set up you can pretty much follow the standard Gentoo installation.
This is the direction I'm trying to push my career.
After 10 years of programming, I'm getting bored with slinging code. Developing prototypes and solving the hard problems is fun, but 75% of coding is routine and unchallenging.
So my career goal is to become a 'Technology Buddah' (from a Dilbert cartoon), dispensing enlightenment to the junior coders who seek my aid. Having an overview of the technological infrastructure, along with the business requirements (see, learning manager-speak already) I hope to become a bridge between management and developers, helping projects get started on the right track and being available to solve unexpected problems.
No need for a manager, so no worries about pay progression. Now, I just have to convince my boss...
Almost. In the spirit of the GPL, the license should be extended to say
"If this software is used for comparative benchmarking purposes, with the results published in advertising materials for a rival database product, then it will be assumed that the rival database developer gives full permission for RedHat to conduct and publish comparative benchmarks against that particular rival product."
How else are you going to prevent MS from pulling another Mindcraft, without RH having the option of rebutting?
Depends - older versions of Oracle default to rule-based optimization, but you can set a DB parameter to use cost-based (stats) by default. The problem with Oracle when I was using it was that it didn't maintain the stats automatically, so they had to be kept up to date or the access plans could be skewed quite dramatically. If Oracle didn't have stats for a particular table it would make assumptions that tended to lead to a silly access path.
My experiece is with Oracle 7 - I expect the query optimzer has changed a bit since then.
Rule based optimization isn't _that_ stupid - it will use indexes where possible, etc. Only when all other things are equal does the order of table names or joins in a query matter. Certainly better than out-of-date or made-up stats; that's why older Oracle programmers tend to prefer rule-based optimization.
It's naive to think that using cost-based optimization you don't have to consider the structure of the DB - a well known example: applying certain functions to an indexed column can lead to inefficient access paths.
OTOH, as an Oracle developer I find it amazing that I have to manually re-compile my DB2 stored procedures if the database statistics change, or an index is added. Oracle programmer's dont have to worry about this stuff. Add an index? Update the stats? The new information will be used immediately.
As always, what you're used to is 'natural' and anything else is 'weird'
When the logs fill up (which incidentally happened a few minutes ago) we get a 'logs are full' message; (why can't we have dynamically re-sizing log files?) This is different - we force a 'run-away' job (no idea why it ran away), and the database stops.
Integrity is great, but the design of DB2 is such that it's too easy to get into a state of questionable integrity, at which point DB2 stops. Just run a LOAD statement and leave out the word 'UNRECOVERABLE' - bam! Tablespace is in backup pending state and you can't access the data. Hence the practice of 1 tablespace per table.
On-line backups have only just been added to the Unix version of DB2, so I expect they operate in quite a different way from OS/390; the documentation is very vague.
I'm not (nor do I want to be) a DBA, but I'll be doing some training when the IBM circus comes to town.
Thanks for the info on lock escalation - I'll look into that and see if that helps.
We own piles of IBM servers, some of which come with DB2 licences, so we thought we might as well use them. Plus, if the load gets too much for our little 4 CPU Netfinity box, we can move up to an AS400 without worrying about porting issues.
I'd be much more enthusiatic about PostgreSQL if it was a 'proper' OODB - methods on classes, collections rather than tables and all that. It seems to be a solid database, now they need to add the nifty features that will make it stand out from the crowd.
Don't discount the value of a decent stored-procedure language - there's a serious impedance mismatch between the low level systems languages (certainly C, and to an extent Java) and more SQL-like declarative languages.
Two of my main uses for stored procedures are parameter-driven queries (which have some complex processing to decide what query to run) and data munging. Both of these cases are query/update bound, so you won't benefit much from the improved performance of a compiled language, and you have to spend all that extra time dealing with the baggage, creating variables, #including, sizing variables, pre-processing, compiling, installing, etc. Not to mention if (like I used to do) you have to support around a dozen platforms, each with their own cc wrinkles. And then there's VAXen...
In this situation a procedural SQL language helps quite a bit, and Oracle's PL/SQL is a gazillion times better than T/SQL (SQL Server) or DB2's procedural SQL solution.
PL/SQL has proper exception handling, DB2 has a sort of ON ERROR GOTO, not as good as proper exception handling but does the job. T/SQL's error handling is right up there with C - an errorlevel variable, which means you have an ugly mix of error handling and normal code.
In PL/SQL you can declare variables to be of table.column%type, so if the table definition changes (say you make a varchar column longer), stored procedures will automagically keep on working. Saves some MAJOR maintenance headaches if you use this properly. SQL Server lets you declare your own data types, but you would end up with hundreds of the things, practically one for every column in every table, which is complete overkill. DB2 doesn't seem to have the concept of column data types.
The source for a PL/SQL stored proc can be stored in the database, so you don't have to worry about losing it. SQL Server does this, too (although I'm not sure if you can remove it for a production environment like Oracle can). DB2 pre-compiles the stored proc and doesn't keep the source (and, as I noted previously, sets the query plan at compilation time.), so you can't browse around a DB looking at the source code for the stored procs to figure out which version of your code they're running.
Oracle and DB2 have cursor loops, with automatically declared local vars for each column in a query. In SQL Server you're expected to DECLARE vars for each column, then FETCH columnlist INTO varlist. Imagine your query returns 50 columns - that's a whole pile of unnecessary code to maintain.
Also (and this REALLY bugs me) in DB2 when a stored proc returns a recordset, it DOESN'T RETURN THE COLUMN NAMES! I couldn't believe it to begin with, this means if you add or re-order the columns in a table, all your code (which has to use integers to index the columns) will be wrecked.
I've used Oracle (on AIX, adminned by pros), SQL Server (adminned by me and MCSEs) and most recently DB2 (on Linux, adminned by me).
I have to say out of all these, SQL Server is easiest to admin, but as a DB needs constant nursing.
DB2 needs a moderate level of nursing. I have found it to be 'moody' - killing a long-running batch job sometimes seems to stop the DB, and it's far too easy to get the database into a 'backup pending' state where everything refuses to run until you execute an off-line backup.
We also have problems where a batch process seems to lock an entire tablespace, blocking other updates. An experienced DB2 DBA told me that standard practice was for each table to have its own tablespace (kinda like MySQL), which seems to me to be a bit of an admin headache when you want to e.g. change settings for a group of tables.
On-line backups seem to back up all transactions since the last off-line backup, so eventually you have to take the DB down and do an off-line backup so you can clear the logs.
Maybe some of the problems I've had with DB2 are answered in the docs. They're comprehensive, but it's next to impossible to find anything. I usually resort to grepping the HTML tree.
Oracle needs the least nursing; I haven't adminned it, but I've worked on sites which have no DBA, where the database has run happily for months. No doubt a pain to set it up properly, but (like Unix) once it's going you can (in theory) forget about it and get on with some work.
As a developer I must say I prefer Oracle to DB2 and SQL Server; Oracle's stored procedure language (PL/SQL) is much more powerful than either DB2 or SQL Server - you can actually do useful things without resorting to C, Java or Visual Basic.
Contrary to what was said above, Oracle has had stats-based query optimization since at least V7; IDK how the query optimization compares with DB2 (although I've managed to write some some slow queries in both languages that benefitted from simple re-arrangement), but one thing I have learned - DB2 makes the query plan when a statement is compiled, and doesn't change it thereafter. Oracle makes the query plan at execution time (and caches it for efficiency) this means that if the nature of your data changes, or you add new indices, you have to re-compile the queries stored in DB2 or it will continue to use inefficient query plans. I consider this extremely stupid.
There was an excellent shareware developer/admin tool for Oracle called TOAD, that did pretty much everything you could want; I'd kill for something similar for DB2.
Oracle's docs are also much more usable, and (most importantly of all) there's a pile of good O'Reilly books covering all aspects of using Oracle.
Slashdot Mirror
The main reason that multi-threaded programming is the in thing is that process creation on Windows is many times slower than thread creation. You can see this if you compare the performance of a complex shell script on Unix vs. Windows. See also Apache 1 vs Apache 2.
Right now C (and other iterative languages) are starting to look like assembler was in the 50s and 60s, lots of people insisting that the only way to get decent performance was to program at the lowest level possible. As the number of cores increases we're going to have to accept that the shared-nothing approach of functional style languages will be better suited to exploit these resources, even if they are slower on smaller scale SMP systems.
Note quite.
1. The SMS only happens if you actually try to do a transaction.
2. The SMS also supplies destination account and amount.
So MIM would only work iff they intercepted an attempt by me to make a payment, and I didn't check the details in the SMS. If I get a transfer SMS out of the blue then I know something's up.
If I lose my mobile then I do what our stone-age ancestors did, and actually go to the physical bank building and fill out a transfer request.
If I make regular payments to a particular account I can also preset the details and avoid the SMS procedure. Requires some paperwork at the bank, though, so they can verify my identity then.
My bank sends me an SMS with a one-time password every time I do a transaction online. You have to type in the password on the web page to confirm the transaction.
I recommend the TargetAlert extension.
The Design Museum in London has a whole section devoted to the presentation of information and the way bias can be introduced depending on the method selected.
They have everything from pie-charts prepared by Florence Nightingale comparing the death rates in battle vs. the field hospitals to a graphical representation of the Linux Kernel.
Well worth a look.
You should be able to do this automatically with ImageMagick and a few lines of shell script.
Should really be something like:
I have no knowledge of this page, nor would I be at liberty to disclose this page if it did in fact exist. Sir.
OK, for the record, according to RiDE Magazine Sept 2003 (Issue 100):
Compared leather jackets from the mid 80's, mid 90's and 2003:
Abrasion time
o Mid 80's - 11.8s
o Mid 90's - 26.8s
o 2003 - 70s
Shoulder burst pressure
o Mid 80's - 250kPa
o Mid 90's - 500kPa
o 2003 - 1100kPa
Transmitted force
o Mid 80's - Elbow/58.8kN Shoulder/41.7kN
o Mid 90's - Elbow/74.3kN Shoulder/59.6kN
o 2003 - Elbow/15kN Shoulder/11kN
A friend of mine went through the driver's window of a car that turned while he was overtaking. His shoulder hit the A-pillar. Fortunately his (cordura) jacket had good armour and all he suffered was a bruised shoulder. The car was written off.
I have a RiDE magazine comparison of bike gear through the ages - armour has really improved over the past 5 years.
Decent leathers contain shock absorbing armour - the modern stuff is very effective and would almost certainly have helped reduce your injuries.
Dunno - not much 'deep' knowledge about Windows is transferable to Linux, since they are fundamentally quite different.
/etc, /dev, /proc and so on. I've solved many configuration mysteries by simply grepping through /etc
/proc/pci contains details of the hardware attached to your pci bus.
If you really want to get under the covers then some basic tips:
o It's all about files - that's the single concept that drives pretty much everything. Your initialisation, configuration, hardware devices and system state can all be found in the file system. So learn the FS layout and how to navigate around with ease - commands like find, grep, locate, mount. Know what is found in
o I use gentoo, but not the livecd, so I don't know much about the hardware config stuff. However, Knoppix has excellent hardware detection, so it's often worth booting a Knoppix cd and using lsmod to see what modules (drivers) it's loaded.
o If you're going to try something like gentoo or one of the other minimalist distributions, the best thing to do is take it slowly - don't worry about setting it up for all your hardware, just the basics (keyboard, mouse, CPU, etc). If your hardware isn't too unusual then a vanilla kernel (with no config changes) should probably work.
Once you've got it up and running you can easily go back and add support for stuff like sound cards in the kernel configuration. If you get stuck use grep and find on the kernel source files to look for info about your hardware to help figure out what options you'll need. The file
"Fat" distros like RH, Mandrake, Suse avoid this by compiling support for all hardware and using a program to decide what drivers to load at boot.
X doesn't need as much configuration as it used to but if you have problems try xorgcfg.
o www.linuxforkids.org
HTH
Too true.
How often do I use the silly top speed of my bike? Never.
How often do I use it's incredible cornering ability? Never - if there's a bend in the road it's usually going 'round something I can't see through, don't want to hit a truck or something.
How often do I get to use it's crazy acceleration? Every time I pull up alongside a Porsche, Ferrari, or BMW M-car at the lights. Which isn't very often, because they're usually stuck back in the queue behind a Toyota. Splitting lanes means I get to be at the front of pretty much every red light, so there's always an open road in front.
We've been running DB2 on Linux for nearly 4 years now - it works fine on our quad Xeon box. At first I had a few problems sorting out the weird Mainframe jargon IBM uses for configuration, but once I got it running it hasn't really given any problems.
DBs aren't very big - data for dynamic web pages at 2Gb, and a warehouse at 4Gb.
I'm not a DBA, and it's so low maintenance that really I know very little about it at all, it takes care of itself.
Certainly works better than the SQL Server we have of equivalent vintage, which seems to have a problem scheduling queries - one big query brings the whole system to a crawl. On the DB2 server a big query increases latency slightly, but that's about all you notice.
That's funny - I have here a box running Redhat 7.1 that provides a public share and a PDF printing service, both accessed almost exclusively from Windows NT 4.0 desktop machines. I certainly haven't created Linux accounts for the 200-odd users on the network.
As others have said, compilers can get close enough to a human's performance to make hand coded assembly unnecessary. Other advantages the compiler has include:
o Support for different variations of an architecture. e.g. your carefully tuned 386 code doesn't perform as well as it could on a Pentium.
o Ability to optimize different cases (code size vs. performance) at the flip of a switch.
o You can take advantage of advances in optimization technology. e.g. gcc 3.2 vs 2.95. Hand optimized code can never get any better without human intervention.
As Knuth said, premature optimization is the root of all evil.
I used Tom's Root Boot (http://www.toms.net/rb/). As long as you can get the networking set up you can pretty much follow the standard Gentoo installation.
I want an Evil Tux!
It can lurk on my desk, waiting for innocent MCSEs who try to mess with my workstation.
Maybe I can throw something together with Lego Mindstorms...
This is the direction I'm trying to push my career.
After 10 years of programming, I'm getting bored with slinging code. Developing prototypes and solving the hard problems is fun, but 75% of coding is routine and unchallenging.
So my career goal is to become a 'Technology Buddah' (from a Dilbert cartoon), dispensing enlightenment to the junior coders who seek my aid. Having an overview of the technological infrastructure, along with the business requirements (see, learning manager-speak already) I hope to become a bridge between management and developers, helping projects get started on the right track and being available to solve unexpected problems.
No need for a manager, so no worries about pay progression. Now, I just have to convince my boss...
Almost. In the spirit of the GPL, the license should be extended to say
"If this software is used for comparative benchmarking purposes, with the results published in advertising materials for a rival database product, then it will be assumed that the rival database developer gives full permission for RedHat to conduct and publish comparative benchmarks against that particular rival product."
How else are you going to prevent MS from pulling another Mindcraft, without RH having the option of rebutting?
Handy, thanks.
Depends - older versions of Oracle default to rule-based optimization, but you can set a DB parameter to use cost-based (stats) by default. The problem with Oracle when I was using it was that it didn't maintain the stats automatically, so they had to be kept up to date or the access plans could be skewed quite dramatically. If Oracle didn't have stats for a particular table it would make assumptions that tended to lead to a silly access path.
My experiece is with Oracle 7 - I expect the query optimzer has changed a bit since then.
Rule based optimization isn't _that_ stupid - it will use indexes where possible, etc. Only when all other things are equal does the order of table names or joins in a query matter. Certainly better than out-of-date or made-up stats; that's why older Oracle programmers tend to prefer rule-based optimization.
It's naive to think that using cost-based optimization you don't have to consider the structure of the DB - a well known example: applying certain functions to an indexed column can lead to inefficient access paths.
OTOH, as an Oracle developer I find it amazing that I have to manually re-compile my DB2 stored procedures if the database statistics change, or an index is added. Oracle programmer's dont have to worry about this stuff. Add an index? Update the stats? The new information will be used immediately.
As always, what you're used to is 'natural' and anything else is 'weird'
When the logs fill up (which incidentally happened a few minutes ago) we get a 'logs are full' message; (why can't we have dynamically re-sizing log files?) This is different - we force a 'run-away' job (no idea why it ran away), and the database stops.
Integrity is great, but the design of DB2 is such that it's too easy to get into a state of questionable integrity, at which point DB2 stops. Just run a LOAD statement and leave out the word 'UNRECOVERABLE' - bam! Tablespace is in backup pending state and you can't access the data. Hence the practice of 1 tablespace per table.
On-line backups have only just been added to the Unix version of DB2, so I expect they operate in quite a different way from OS/390; the documentation is very vague.
I'm not (nor do I want to be) a DBA, but I'll be doing some training when the IBM circus comes to town.
Thanks for the info on lock escalation - I'll look into that and see if that helps.
We own piles of IBM servers, some of which come with DB2 licences, so we thought we might as well use them. Plus, if the load gets too much for our little 4 CPU Netfinity box, we can move up to an AS400 without worrying about porting issues.
I'd be much more enthusiatic about PostgreSQL if it was a 'proper' OODB - methods on classes, collections rather than tables and all that. It seems to be a solid database, now they need to add the nifty features that will make it stand out from the crowd.
Don't discount the value of a decent stored-procedure language - there's a serious impedance mismatch between the low level systems languages (certainly C, and to an extent Java) and more SQL-like declarative languages.
Two of my main uses for stored procedures are parameter-driven queries (which have some complex processing to decide what query to run) and data munging. Both of these cases are query/update bound, so you won't benefit much from the improved performance of a compiled language, and you have to spend all that extra time dealing with the baggage, creating variables, #including, sizing variables, pre-processing, compiling, installing, etc. Not to mention if (like I used to do) you have to support around a dozen platforms, each with their own cc wrinkles. And then there's VAXen...
In this situation a procedural SQL language helps quite a bit, and Oracle's PL/SQL is a gazillion times better than T/SQL (SQL Server) or DB2's procedural SQL solution.
PL/SQL has proper exception handling, DB2 has a sort of ON ERROR GOTO, not as good as proper exception handling but does the job. T/SQL's error handling is right up there with C - an errorlevel variable, which means you have an ugly mix of error handling and normal code.
In PL/SQL you can declare variables to be of table.column%type, so if the table definition changes (say you make a varchar column longer), stored procedures will automagically keep on working. Saves some MAJOR maintenance headaches if you use this properly. SQL Server lets you declare your own data types, but you would end up with hundreds of the things, practically one for every column in every table, which is complete overkill. DB2 doesn't seem to have the concept of column data types.
The source for a PL/SQL stored proc can be stored in the database, so you don't have to worry about losing it. SQL Server does this, too (although I'm not sure if you can remove it for a production environment like Oracle can). DB2 pre-compiles the stored proc and doesn't keep the source (and, as I noted previously, sets the query plan at compilation time.), so you can't browse around a DB looking at the source code for the stored procs to figure out which version of your code they're running.
Oracle and DB2 have cursor loops, with automatically declared local vars for each column in a query. In SQL Server you're expected to DECLARE vars for each column, then FETCH columnlist INTO varlist. Imagine your query returns 50 columns - that's a whole pile of unnecessary code to maintain.
Also (and this REALLY bugs me) in DB2 when a stored proc returns a recordset, it DOESN'T RETURN THE COLUMN NAMES! I couldn't believe it to begin with, this means if you add or re-order the columns in a table, all your code (which has to use integers to index the columns) will be wrecked.
All this is IME, I may be wrong about some things
I've used Oracle (on AIX, adminned by pros), SQL Server (adminned by me and MCSEs) and most recently DB2 (on Linux, adminned by me).
I have to say out of all these, SQL Server is easiest to admin, but as a DB needs constant nursing.
DB2 needs a moderate level of nursing. I have found it to be 'moody' - killing a long-running batch job sometimes seems to stop the DB, and it's far too easy to get the database into a 'backup pending' state where everything refuses to run until you execute an off-line backup.
We also have problems where a batch process seems to lock an entire tablespace, blocking other updates. An experienced DB2 DBA told me that standard practice was for each table to have its own tablespace (kinda like MySQL), which seems to me to be a bit of an admin headache when you want to e.g. change settings for a group of tables.
On-line backups seem to back up all transactions since the last off-line backup, so eventually you have to take the DB down and do an off-line backup so you can clear the logs.
Maybe some of the problems I've had with DB2 are answered in the docs. They're comprehensive, but it's next to impossible to find anything. I usually resort to grepping the HTML tree.
Oracle needs the least nursing; I haven't adminned it, but I've worked on sites which have no DBA, where the database has run happily for months. No doubt a pain to set it up properly, but (like Unix) once it's going you can (in theory) forget about it and get on with some work.
As a developer I must say I prefer Oracle to DB2 and SQL Server; Oracle's stored procedure language (PL/SQL) is much more powerful than either DB2 or SQL Server - you can actually do useful things without resorting to C, Java or Visual Basic.
Contrary to what was said above, Oracle has had stats-based query optimization since at least V7; IDK how the query optimization compares with DB2 (although I've managed to write some some slow queries in both languages that benefitted from simple re-arrangement), but one thing I have learned - DB2 makes the query plan when a statement is compiled, and doesn't change it thereafter. Oracle makes the query plan at execution time (and caches it for efficiency) this means that if the nature of your data changes, or you add new indices, you have to re-compile the queries stored in DB2 or it will continue to use inefficient query plans. I consider this extremely stupid.
There was an excellent shareware developer/admin tool for Oracle called TOAD, that did pretty much everything you could want; I'd kill for something similar for DB2.
Oracle's docs are also much more usable, and (most importantly of all) there's a pile of good O'Reilly books covering all aspects of using Oracle.
Like most countries, depends where you go. You have to be pretty streetwise in the cities.