views:

97

answers:

4

I am not a DBA. However, I work on a web application that lives entirely in an Oracle database (Yes, it uses PL/SQL procedures to write HTML to clobs and then vomits the clob at your browser. No, it wasn't my idea. Yes, I'll wait while you go cry.).

We're having some performance issues, and I've been assigned to find some bottlenecks and remove them. How do I go about measuring Oracle performance and finding these bottlenecks? Our unhelpful sysadmin says that Grid Control wasn't helpful, and that he had to rely on "his experience" and queries against the data dictionary and "v$" views.

I'd like to run some tests against my local Oracle instance and see if I can replicate the problems he found so I can make sure my changes are actually improving things. Could someone please point me in the direction of learning how to do this?

+1  A: 

edit:

There's a package called DBMS_PROFILER that lets you do what you want, I think. I found out my IDE will profile PL/SQL code as I would guess many other IDE's do. They probably use this package.

http://www.dba-oracle.com/t%5Fdbms%5Fprofiler.htm

http://www.databasejournal.com/features/oracle/article.php/2197231/Oracles-DBMSPROFILER-PLSQL-Performance-Tuning.htm


edit 2:

I just tried the Profiler out in PL/SQL Developer. It creates a report on the total time and occurrences of snippets of code during runtime and gives code location as unit name and line number.


original:

I'm in the same boat as you, as far as the crazy PL/SQL generated pages go.

I work in a small office with no programmer particularly versed in advanced features of Oracle. We don't have any established methods of measuring and improving performance. But the best bet I'd guess is to try out different PL/SQL IDE's.

I use PL/SQL Developer by Allaround Automations. It's got a testing functionality that lets you debug your PL/SQL code and that may have some benchmarking feature I haven't used yet.

Hope you find a better answer. I'd like to know too. :)

EMPraptor
I'm using SQL Navigator 4, and it seems to have similar functionality. Now I'm trying to figure out how to use it. Thanks for the suggestions.
Jon Renaut
My IDE prompted to let me know it had to create a table to hold the profiler data. I'm guessing you made yourself DBA on your local instance, but if you have trouble with that I'd check the privileges needed to set up and run DBMS_PROFILER. http://oracleprofessional.blogspot.com/2004/09/dbmsprofiler-for-code-coverage.html
EMPraptor
+2  A: 

It can be overwhelming to analyze database performance with Grid Control, and I would suggest starting with the simplier AWR report - you can find the scripts to generate them in $ORACLE_HOME/rdbms/admin on the db host. This report will rank the SQL seen in the database by various categories (e.g. CPU time, disk i/o, elapsed time) and give you an idea where the bottlenecks are on the database side.

One advantage of the AWR report is that it is a SQL*Plus script and can be run from any client - it will spool HTML or text files to your client.

dpbradley
I tried AWR, and the results might as well have been in ancient Greek. I guess I have to do some research on interpreting the stuff it spits out. Thanks.
Jon Renaut
Sorry, I tried ASH, not AWR. I'll look into AWR now.
Jon Renaut
+3  A: 

Not too surprising there are entire books written on this topic.

Really what you need to do is divide and conquer.

First thing is to just ask yourself some standard common sense questions. Has performance slowly degraded or was there a big drop in performance recently is an example.

After the obvious a good starting point for you would be to narrow down where to spend your time - top queries is a decent start for you. This will give you particular queries which run for a long time.

If you know specifically what screens in you front-end are slow and you know what stored procedures go with that, I'd put some logging. Simple DBMS_OUTPUT.put_lines with some wall clock information at key points. Then I'd run those interactively in SQLNavigator to see what part of the stored procedure is going slow.

Once you start narrowing it down you can look to evaluate why a particular query is going slow. EXPLAIN_PLAN will be your best friend to start with.

David
I've made some progress in this direction. I suspect it will eventually get me where I need to be. I'll let everyone know.
Jon Renaut
A: 

"I work on a web application that lives entirely in an Oracle database (Yes, it uses PL/SQL procedures to write HTML to clobs and then vomits the clob at your browser"

Is it the Apex product ? That's the web application environment now included as standard part of the Oracle database (although technically it doesn't spit out CLOBs).

If so there is a whole bunch of instrumentation already built in to the product/environment (eg it keeps a rolling two-week history of activity).

Gary
No, my understanding is that my predecessors rolled their own.
Jon Renaut