joel-garry_at_home.com wrote:
>>Billing is seldom an OLTP process.
>
>
> Wow, I guess I work on a rare system. Invoices are generated as items
> are shipped. (The invoice printing is pseudobatch, though, since that
> is done by different department).
>
> Of course, there is a lot about the system that would be considered
> poor design, as it is one of those "database-independent" thingies.
>
> So I agree with Daniel and Sybrand, poor design, but agree with Mark
> about the concurrency thing. In fact, the system can choke on locks if
> it hits concurrency or wait issues - it gives the user the choice to
> wait or bail (like if a warehouse peon goes to lunch in the middle of
> updating inventory and someone else needs that spot - easily resolved
> with Oracle lock manager). Although, I actually got a ORA-60 last
> week. Scratched my head, until I noticed the trace file has osuser
> id's, and I was able to determine someone hit a lock (this was on a
> different system than the above), called up someone else who then ran
> the same single-user batch update while the first was still locked.
> Sheesh. But while technically "bad," the design has been mostly wrung
> out and generally works well, and gives all source code. I've
> certainly seen worse in all those areas. Perhaps the worst part is it
> is so easy to customize the design tends to deteriorate towards non-R
> business processes. Those darn business people!
Every symptom you discuss screams design and code problems easily
resolved. One thing you can, and if you are in the US, do immediately
is set resource_limit = TRUE then modify the default profile. Tell them
it is for SarbOx and FACTA compliance.
--
Daniel A. Morgan
http://www.psoug.org
damorgan_at_x.washington.edu
(replace x with u to respond)
Received on Thu Jul 07 2005 - 22:54:40 CDT
