Databases tend to get split up into a variety of diffrent catagoies based on their application and requirements. All of these diffrent catagories naturally get nifty buzz words to help classify them and make distinctions in features more apparent. The most popular buzz work (well, acronymn anyway) is OLTP or Online Transaction Proccessing. Other classifications include Descision Support Systems (DSS), Data Warehouses, Data Marts, etc.
OLTP databases, as the name implies, handle real time transactions which inherently have some special requirements. If your running a store, for instance, you need to ensure that as people order products they are properly and effiently updating the inventory tables while they are updating the purchases tables, while their updating the customer tables, so on and so forth. OLTP databases must be atomic in nature (an entire transaction either succeeds or fails, there is no middle ground), be consistant (each transaction leaves the affected data in a consistant and correct state), be isolated (no transaction affects the states of other transactions), and be durable (changes resulting from commited transactions are persistant). All of this can be a fairly tall order but is essential to running a successful OLTP database.
Because OLTP databases tend to be the real front line warriors, as far as databases go, they need to be extremely robust and scalable to meet needs as they grow. Whereas an undersized DSS database might force you to go to lunch early an undersized OLTP database will cost you customers. No body is going to order books from an online book store if the OLTP database can't update their shopping cart in less than 15 seconds.
The OLTP feature you tend to hear most often is "row level locking", in which a given record in a table can be locked from updates by any other proccess untill the transaction on that record is complete. This is akin to mutex locks in POSIX threading. In fact OLTP shares a number of the same problems programmers do in concurrent programming. Just as you'll find anywhere, when you've got a bunch of diffrent persons or proccesses all grabbing for the same thing at the same time (or at least the potential for that to occur) your going to run into problems and raw performance (getting your hands in and out as quick as possible) is generally one of the solutions.
Several other factors come into place with OLTP databases, and the Oracle10g documentation library even has a whole section dedicated just to OLTP. Find more information in the Oracle10g docs:
http://www.oracle.com/pls/db10g/portal.portal_demo3?selected=18