Thanks Dennis. As you know, I work outward into the application from the trace file that tells me where a system is spending its time. One really common place for applications to spend users' time is in the communications round trips with the database. Every round-trip is, of course, motivated by the application source code somehow. So this typically motivates me to study the application's interface to the database (the db driver) and how the application code makes calls to it (whether the calls are inside loops, and things like that). I think you're right on target with the PreparedStatement quest, and in general learning the details of how the application interfaces with the database. If you're unlucky enough to live in one of these worlds that attempts pure object-oriented development (for example, every table has an OO Java access method, and joins are done in Java instead of in Oracle), then your performance is probably going to be catastrophic until either you conquer enormous political summits or you find a new place to work. (Of course, if you find a new place to work, the performance problem doesn't go away, it's just not /your/ performance problem anymore ;) ). But you can't even attempt to climb a political hill like the one to gut and rewrite an application unless you know enough about the application development language to speak in the application design (or re-design) meetings. Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com * Nullius in verba * Upcoming events: - Performance Diagnosis 101: 4/6 Seattle, 5/7 Dallas, 5/18 New Jersey - SQL Optimization 101: 4/19 Denver, 5/3 Boston, 5/24 San Diego - Hotsos Symposium 2005: March 6-10 Dallas - Visit www.hotsos.com for schedule details... -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of DENNIS WILLIAMS Sent: Friday, April 02, 2004 10:14 AM To: 'oracle-l@xxxxxxxxxxxxx' Subject: RE: Java vs. Perl Cary Well said, as always. Can you pinpoint any parts of Java that are good for a DBA to concentrate on? I've learned just enough OOP to understand that languages like Java don't always lend themselves to clear transaction boundaries. Mostly I've used that as a well of empathy so I can look sympathetic and nod and agree and then say "yeah but you've got to figure it out somehow." I push the Java developers to use PreparedStatement. This causes Java to use bind variables. If I tell a Java developer to use bind variables, they look blankly, but they do understand PreparedStatement, or can at least go back and look it up in a book. Aside from the benefits in Oracle, it also defeats the SQL Injection hacking technique. I would gratefully appreciate any other points you would care to share. Dennis Williams DBA Lifetouch, Inc. dwilliams@xxxxxxxxxxxxx -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Cary Millsap Sent: Friday, April 02, 2004 9:51 AM To: oracle-l@xxxxxxxxxxxxx Subject: RE: Java vs. Perl The only reason I would recommend for a DBA to learn Java is if that's what your applications are written in. If you have any performance responsibilities, you MUST know something about the language your apps are written in. Substitute whatever your app is written in for "Java" in this paragraph (PHP, COBOL, C++, C#, Visual Basic, ...it doesn't matter; whatever your app is written in). This, by the way, is why you MUST understand SQL and probably also PL/SQL (if you're lucky); it's part of what your apps are written in. Perl is another story. Maybe your app is written in Perl, but probably not. Even so, Perl, Python, ksh, SQL, PL/SQL, and others are tools that a DBA might use to create new tools that help you do your job more effectively. There's probably someone out there who writes DBA scripts in Java, but whoever you are, I don't envy you. :) Cary Millsap Hotsos Enterprises, Ltd. http://www.hotsos.com * Nullius in verba * Upcoming events: - Performance Diagnosis 101: 4/6 Seattle, 5/7 Dallas, 5/18 New Jersey - SQL Optimization 101: 4/19 Denver, 5/3 Boston, 5/24 San Diego - Hotsos Symposium 2005: March 6-10 Dallas - Visit www.hotsos.com for schedule details... -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of David Lee Sent: Friday, April 02, 2004 9:37 AM To: oracle-l@xxxxxxxxxxxxx Subject: RE: Java vs. Perl There are many reasons to use one tool over another. For me and my company, perl offers faster development time. What it boils down to, both tools allow you to connect to the Database so anything that can execute SQL or pl/sql is fine. In the past, executing the same business logic with medium to big amount of data (100k+ records) is faster in perl than java. Unfortunately I=20 don't have any statistics to back to support this. Anyone? The java developers that I know of, uses ODBC or OCI, to communicate = from the java application server (ATG) to 8i. I don't know of anyone using=20 java and communicating to Oracle's API. =20 - David Lee -----Original Message----- From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Juan Cachito Reyes Pacheco Sent: Friday, April 02, 2004 10:04 AM To: oracle-l@xxxxxxxxxxxxx Subject: Java vs. Perl Hi, please there is another reason than simple know perl, to use perl instead of Java. I always heard Java had more advantages than perl, including the fact = that Oracle include it in the database. Now you are talking as much about perl, and I am thinking to study java, = I am asking which is best. for most purpouses. Thanks :) Juan Carlos Reyes Pacheco OCP Database 9.2 Standard Edition ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html ----------------------------------------------------------------- ---------------------------------------------------------------- Please see the official ORACLE-L FAQ: http://www.orafaq.com ---------------------------------------------------------------- To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------