Next: Data Warehousing and Data
Up: Loose Ends
Previous: Data Guard
Contents
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
Next: Data Warehousing and Data
Up: Loose Ends
Previous: Data Guard
Contents
2005-02-10