Oracle (not Rdb) database

Bill D Michael Bill.Michael@ipaper.com
Fri, 22 Jun 2001 11:36:28 -0500


Because otherwise it locks the entire table (or attempts to) by default ,
which causes "hangs" on Quick screens (recently fixed to at least give the
"waiting on lock" message...) if successful, or extremely long run times
and possible failure timeouts if it can't get the whole table. We have a
submitted batch process to print orders (and set a flag as "printed", thus
requiring update of the tables) when the user finishes entering one on the
screens - it and the screens obviously need access to our order tables.
When we just switched from RMS files to Oracle 8i tables - no other changes
- we went from a couple of seconds to print an order, to minutes or even
hours due to batch queue backlogs. SET LOCK RECORD UPDATE brought this back
down to under a minute. Still much slower, but livable.

Batch processes running when no users are online can lock a table; but
anything that runs outside our very narrow batch-only window had to be
modified to pacify the lynch mob that was forming outside my door. Why was
it never a problem going against RMS files? I dunno - Cognos swears there
were no changes between 7.10 and 8.20 on locking strategy, and that what
we're seeing now is normal, no idea why it was working "differently"
before. However, we are seeing many more locking problems even on programs
that have not yet been converted to hit Oracle...

Bill





Mark Stewart <stewm@canada.com>@cube.swau.edu on 06/21/2001 08:29:25 PM

Sent by:  powerh-l-admin@cube.swau.edu



To:   Bill.Michael@ipaper.com
cc:   chalenburg@harding.edu, powerh-l@lists.swau.edu
Subject:  Re: Oracle (not Rdb) database


Bill,

I aggree with COMMIT AT 1 TRANSACTION which is the same as COMMIT AT
UPDATE.  This sets your transaction model to concurrency.  However I'm kind
of uncertain as to why you would highly recommend putting SET LOCK RECORD
UPDATE in every QTP source.

Mark

On Thu, 21 June 2001, "Bill D Michael" wrote:

>
>
> PH 8.20D6 will allow you to access Oracle 8i tables, same as if they were
> RMS files, with minimal effort, for things like QUIZ. (Or indeed any
"read
> only" access, REFERENCE files in Quick and such.) So writing new code to
> access your new database should not be that bad. Even "simple" Quick
> screens aren't bad, as long as you're careful with locking and COMMITs.
QTP
> can easily lock up your whole system if you let it take the defaults -
> COMMIT AT 1 TRANSACTION and SET LOCK RECORD UPDATE in every source is
> highly recommended! (Also recommend _not_ using SUBDICT=SEARCH; go ahead
> and specify the database name everywhere.)
>
> However, I would be very careful in just "upgrading" from 7.10 to 8.20,
> regarding your current applications that will be staying around, whether
> they'll be touching Oracle or not. This is a nightmare to do, primarily
due
> to two factors; the removal of "VMSisms" from 8.xx, and the large number
of
> serious bugs in 8.20. 8.30 is rumored to be much easier to move to on the
> "VMSisms", but of course it's going to be out "real soon now", and hasn't
> yet been through the painful debugging 8.10/8.20 has over the last couple
> of years. If I were in your situation, I'd get 8.20 for "new stuff", but
> keep 7.10 for the existing code.
>
> I'd also rethink running Oracle 8 on VMS. There are a number of
> problems/issues there that (apparently) aren't a problem on other
> platforms. Given the ideal situation (if PH/Oracle/VMS can ever be
> idealized!), I'd put the Oracle off on a Unix box, with the PowerHouse
app
> on VMS... If you have to keep it all on "one box", plan on doubling the
> horsepower of that box, or you're not going to be happy with the
> performance.
>
> Bill
>
>
>
>
>
> Mike Chalenburg <chalenburg@harding.edu>@cube.swau.edu on 06/21/2001
> 11:07:08 AM
>
> Please respond to chalenburg@harding.edu
>
> Sent by:  powerh-l-admin@cube.swau.edu
>
>
>
> To:   powerh-l@lists.swau.edu
> cc:
> Subject:  Oracle (not Rdb) database
>
>
> Good morning,
>
> Given the current thread on Rdb, I'd like to get advice on a separate but
> related topic.
>
> We are running an Alpha cluster with VMS 7.2-1 (soon to be 7.3) and
> Powerhouse 7.10F2.  After years of home grown software, about 95% in
> Powerhouse, we are moving to a 3rd party vendor for all of our
> applications.
> We are down to two vendors and the similarity is that they both run on
> Oracle 8.1.7 (not Rdb).  We intend to run the database server portion on
> the
> VMS cluster.
>
> There are a few of our applications that will not be replaced by the 3rd
> party product.  Also it would be very helpful to be able to modify some
of
> our applications to look at the Oracle database.  Is any of this
feasible?
> What kinds of pitfalls are there?  I had understood that we would be able
> to
> use Powerhouse to access the Oracle database.  Is that correct?
>
> Thanks for your help.
>
> Mike
>
> |------------------------------------------------------------|
> | Mike Chalenburg         |  Harding University              |
> | chalenburg@harding.edu  |  Information Technology Services |
> | 501-279-4041            |  Manager, MIS                    |
> |------------------------------------------------------------|
>         The opinions expressed are those of the writer
>        and not necessarily those of Harding University.
>
>
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
> powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.
>
>
>
>
> = = = = = = = = = = = = = = = = = = = = = = = = = = = =
> Mailing list: powerh-l@lists.swau.edu
> Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
> Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
> http://lists.swau.edu/mailman/listinfo/powerh-l
> This list is closed, thus to post to the list you must be a subscriber.


__________________________________________________________
Get your FREE personalized e-mail at http://www.canada.com

= = = = = = = = = = = = = = = = = = = = = = = = = = = =
Mailing list: powerh-l@lists.swau.edu
Subscribe: "subscribe" in message body to powerh-l-request@lists.swau.edu
Unsubscribe: "unsubscribe" in message body to
powerh-l-request@lists.swau.edu
http://lists.swau.edu/mailman/listinfo/powerh-l
This list is closed, thus to post to the list you must be a subscriber.