Oracle 12c

Wed Nov 16 06:59:18 CST 2016

Yea, I know what you are talking about on the reward/effort cursor/select/choose thing.  I attacked our month end run changing selects to chooses, (even chooses on un-indexed items, with a remote DB, it pays to be as selective as possible with what you throw across the wire).  (We front end our qtp/quiz calls with a shell wrapper that both hides where the quiz/qtp are running from, as well as giving a start/stop time log, so I knew where to target).  Took the thing down from 14 hours to just over 40 minutes, without changing the core logic in any of the code, just shifting selects into chooses where possible, and changing "select" on compound statements into a set of
"select file if" statements.  (You can choose on the 1st file in the access, and continue with a "select if" or set of "select file if" statements after that).

Times change, rules change, but the rule "used to be"

Select fires after a record complex is built, (header, detail, reference things).

Select File fires as the file is referenced, and aborts building the rest of the complex.

So if you start at order_header, link over to order_detail, then to the product master,

A simple select fires after you have gathered all 3 records.  (Send me all the data that I may throw away the 99% I don't want).

A choose on order_header only returns orders of interest (say status in "A").

A select order_detail  will short circuit at order_detail and not grab the product record if the order_detail filters out.

At the lowest level (product master) it doesn't really matter if you "select file if" or "select if", by that time
You have built the entire record complex.

Generally pays to choose up front, and select/short circuit building the record complex as quickly as possible, esp. with a non-local database.

Of course, doing something like this "a decade or so ago" leaves you open to the question
"What have you done for me, LATELY".

IT is a treadmill, it will throw you off if you don't keep up with the times.

From: Peter Hofstaetter [mailto:Peter.Hofstaetter at fujixerox.com]
Sent: Tuesday, November 15, 2016 4:41 PM
To: Ken Langendock <Ken at Langendock.com>; Herald Kaffka <Herald.Kaffka at westfraser.com>; powerh-l at lists.sowder.com
Subject: RE: Oracle 12c

Yes, I know but that is a lot more work and not sure how long we will have the app for. Where performance has been that bad and choose hasn't helped that much I have replaced the access with SQL.

From: Ken Langendock [mailto:Ken at Langendock.com]
Sent: Wednesday, 16 November 2016 8:13 AM
To: Peter Hofstaetter; 'Herald Kaffka'; powerh-l at lists.sowder.com<mailto:powerh-l at lists.sowder.com>
Subject: RE: Oracle 12c

Peter

If you are running PH against an Oracle DB, you should be changing all your access statements to CURSOR/FETCH statements.
WAY faster.

From: Peter Hofstaetter [mailto:Peter.Hofstaetter at fujixerox.com]
Sent: November 15, 2016 3:42 PM
To: Herald Kaffka <Herald.Kaffka at westfraser.com<mailto:Herald.Kaffka at westfraser.com>>; Ken Langendock <Ken at Langendock.com<mailto:Ken at Langendock.com>>; powerh-l at lists.sowder.com<mailto:powerh-l at lists.sowder.com>
Subject: RE: Oracle 12c

Thanks guys.

You have been a great help.

And for Herald, yes we are running a separate DB server on Linux and I am aware of the difference between choose and select. It's a great trick using choose. Most people don't even realise you can choose non index fields to offload the selection process onto the DB server instead of locally by Powerhouse. It has been my mission to improve the performance of all the code written to replace as many selects as possible particularly now that the application has been running for so long to start seeing the difference with larger table sizes. In some cases reducing reports from minutes to run down to seconds.

From: Herald Kaffka [mailto:Herald.Kaffka at westfraser.com]
Sent: Wednesday, 16 November 2016 1:39 AM
To: Ken Langendock; Peter Hofstaetter; powerh-l at lists.sowder.com<mailto:powerh-l at lists.sowder.com>
Subject: RE: Oracle 12c

You may be right.

You made me go look/check.   Thought my dev environments had been upgraded to 12C as part
Of a machine move/change awhile back, but turns out they are actually still on 11.2.0.4.0.

Application here is a relatively simple (but large) "text based" app.  (No BLOBS/CLOBS etal, just numbers, dates, char/varchar fields).
Remember doing some dancing with dates on the migration to oracle (stored as nulls, with the zero's being used as a runtime replacement within the app, but nothing else "fancy").

Doubt we will ever go to 12c at this point, application is scheduled to replace by a commercial package within the next year, will probably rest "as is" until then...

From: powerh-l-bounces+herald.kaffka=westfraser.com at lists.sowder.com<mailto:powerh-l-bounces+herald.kaffka=westfraser.com at lists.sowder.com> [mailto:powerh-l-bounces+herald.kaffka=westfraser.com at lists.sowder.com] On Behalf Of Ken Langendock
Sent: Tuesday, November 15, 2016 8:10 AM
To: 'Peter Hofstaetter' <Peter.Hofstaetter at fujixerox.com<mailto:Peter.Hofstaetter at fujixerox.com>>; powerh-l at lists.sowder.com<mailto:powerh-l at lists.sowder.com>
Subject: RE: Oracle 12c

Do NOT upgrade to Oracle 12C.
PH does not work with that version. It does not even talk to it.
We spent weeks trying to get it to work.
Until Unicom gets off their collective butts (excessive fee collection) and releases a new version of PH, stay on Oracle 11G.

From: powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com<mailto:powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com> [mailto:powerh-l-bounces+ken.langendock=rogers.com at lists.sowder.com] On Behalf Of Peter Hofstaetter
Sent: November 14, 2016 7:32 PM
To: powerh-l at lists.sowder.com<mailto:powerh-l at lists.sowder.com>
Subject: Oracle 12c

We are running PowerHouse 8.43.D1 on Solaris 10 using the 9.2 client and have upgraded to Oracle 11g and all seems to be OK for almost a year.

We are now looking at migrating to Oracle 12c but found that we need to upgrade client as 9.2 will not talk to 12c database which also means that we need to upgrade to Solaris 11 to use the newer clients.

What we have found is that we cannot find any combination of client that will talk to 12c database without causing errors - mostly ORA-01024: invalid datatype in OCI call, but have had other errors also.

Has anyone migrated to 12c and if so what client are you using and how do you have it configured?

Thanks in advance.

Peter

IMPORTANT NOTE: Fuji Xerox email transmission, including any attachments, is private and confidential and may contain legally privileged information. It is for the addressee's attention only. If you are not the intended recipient and have received this transmission, you must not use, edit, print, copy or disclose its contents to any person or disseminate the information contained herein or hereto attached, and you must notify sender immediately by return email and delete this transmission from your system. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. We have used reasonable efforts to protect this transmission from computer viruses and other malicious software, but no warranty is made and the sender takes no responsibility for any loss or damage incurred from using this email or the information contained in this email.

-------------EOP---------------

This e-mail message and any attachments are confidential. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. If you are not the intended recipient, please notify me by return e-mail, do not open any attachment and delete this communication and any copy.

Thank you

IMPORTANT NOTE: Fuji Xerox email transmission, including any attachments, is private and confidential and may contain legally privileged information. It is for the addressee's attention only. If you are not the intended recipient and have received this transmission, you must not use, edit, print, copy or disclose its contents to any person or disseminate the information contained herein or hereto attached, and you must notify sender immediately by return email and delete this transmission from your system. Any confidentiality, privilege or copyright is not waived or lost because this e-mail has been sent to you in error. We have used reasonable efforts to protect this transmission from computer viruses and other malicious software, but no warranty is made and the sender takes no responsibility for any loss or damage incurred from using this email or the information contained in this email.

-------------EOP---------------

This e-mail message and any attachments are confidential. Any dissemination or use of this information by a person other than the intended recipient is unauthorized. If you are not the intended recipient, please notify me by return e-mail, do not open any attachment and delete this communication and any copy.

Thank you
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sowder.com/pipermail/powerh-l/attachments/20161116/a607133f/attachment-0001.htm>