s2k Demo
========

THIS CODE IS DELIBERATELY BAD AND MOSTLY POINTLESS. IT IS NOT A GOOD
EXAMPLE OF ANYTHING EXCEPT BAD PROGRAMMING.

These programs are examples intended to run against the standard sports2000
database (or "bigsports") to illustrate various problematic code behavior.

THE DATABASE MUST BE NAMED "sports2000", "s2k", or "bigsports". OTHER
DATABASE NAMES WILL NOT WORK WITH THIS CODE.

If you want meaningful user names first load _User.d

Some of these examples will work better with a larger than default version
of the database. The Consultingwerk "bigsports" db is helpful for that
purpose.

The programs launched by the demo* scripts can be gracefully shutdown by
removing their corresponding *.flg files.

It is helpful to enable client-statement caching globally prior to running
these programs (the sample db startup scripts do this automatically).

The ProTop ChUI "dot" options will start and stop these demos.  Type
".h" for help when inside ProTop.


churn.p
-------

Churns away at the vacation table (12 records). The point of this is to:

  a) simulate the very common application issue of very small and
     very avtive tables

  b) simulate a "rapid reader" that is entirely in memory

  c) drive latch contention issues by permitting multiple instances
     to run simultaneously


lockalot.p
----------

Obtains a large but randomly varying number of record locks on the
purchaseOrder and poLine tables.

This is helpful when showing how to find sessions that consume many -L
entries (as opposed to a high locking *rate*).


badtrx.p
--------

Example of bad TRX scoping that will result in bi growth if some OTHER
process is doing work. This is an example of the classic user who is doing
*nothing* but has left their session open with a TRX active and the
problems that that can cause.


updorder.p
----------

Randomly updates an order's salesRep. This program does not do anything
"wrong".  But when run while badtrx.p is active it will demonstrate how
a poorly scoped transaction in one program will cause problems when an
otherwise innocent program runs.

The program also randomly sets order.orderDate to TODAY in order to feed
the "user defined metric" on the ProTop dashboard.


blocker.p
---------

Grabs an exclsuive-lock on the first feedback record so that victim.p will
block when it tries to do the same thing.  This provides an opportunity to
show a "blocked user" on the ProTop "b" screen.


victim.p
--------

Tries to get an exclusive-lock on feedback. Gets stuck waiting because
blocker.p already has one.

Be careful not to wait too long.  If -lkwtmo expires you may need to
restart victim.p


@@@@@@@@@@

The following programs are NOT automatically run by demo*, they must be
manually started.


badorder.p
----------

Finds orders that are missing order lines, bill to, *and* purchase orders.
This is deliberately horrible code that will cause very intense db
activity.

Of particular interest is the unbalanced relationship between table reads
and index reads.
