Forms 10g App. is slow: What is the official procedure to follow?

Question

Hello Forms gurus. This question has been bugging me for some time. Here is the scenario.
We have a Telco application developed using Forms 10g.
A user complains that his form is slow.
We have access to the live DB (assume it is a 10g DB).
However, we cannot run the form in the live DB. We have no access to it. We only have access to the live DB.
What is the "procedure" to follow in a situation like this???
Is there an Oracle Recommended procedure to follow?
You inputs will be greatly appreciated.

Answer 1

Are you sure the database is the cause of your performance problems? Can you identify slow queries? The first thing you should investigate is *where* your problem relies. Ask your DBAs if they can tell you the bad performing queries or help you analyze if there are any. If the database behaves well then most certainly it isn't the culprit of your performance problem. Of course there are some other no-gos which might affect application performance (like slow-by-slow processing, or serializing, or what ever else). So you need to identify where the time is spent first.
So, according to the them, if a form is "slow", 99.99% it is caused by a slow query.  So, they expect us developers to know tuning stuff.
Erm...and who else should know it? Developers design the application, developers know how it should work, and therefore are the ones who should know how to tune it. And I'm not talking about looking into why the Hard disk responds slow kind of stuff but simple identifying sub-optimal code, or SQL tuning by looking at the execution plans, interpreting them and solving them by...oh, I don't know, rewriting the query, minimizing recursive SQL, and what ever else. DBAs on the other hand know next to nothing about your application. How should they know if a query plan is bad or not (except the query responds slow)? How should they know how to rewrite your query properly if they don't know what it's supposed to do? Don't write a query whatever way you like and expect them to understand it and tune it which might even imply changes on your underlying data model.
There are 2 scenarios:
(1.) We got e-mail from user saying form is slow. But he is not using the form now.
         -- Is there a way to find out slow queries that happened say few days ago? Are they stored somewhere?
(2.) User is currently logged on to the system and using the form.
        -- Can you find out an slow query happening right now??
1.) This would be AWR. As they have the final saying about the database then ask them to provide you a AWR report of a Time period where you had performance problems. If you don't have AWR then it'll be somehow difficult to analyze performance problems of the past. But on the other hand I wouldn't worry too much if you can constantly reproduce your problems as this would take us straight foreward to:
2.) That would be SQL Trace. Simply trace the session experiencing performance problems, and run tkprof on the tracefile. If you don't know how to do that and don't know how to interpret a query plan then you might ask your DBAs if they can assist you. If they insist that you must know that on your own maybe ask them to teach you. It is one thing to ask someone to do your job, but an entirely other thing to ask someone for help to do your job better and share some knowledge.
In the end it'll be easier to work *with* your DBAs to identify and solve performance problems and not working *against* them. You have knowledge about your application, about what data is stored where and why but might lack some basic knowledge about SQL Tuning. Your DBA on the other hand has no knowledge about your application but might have a better understanding of basic SQL tuning. IMHO the both of you would make a good couple to solve SQL performance problems as your knowledge combined should make it easy to resolve your problem.
cheers