Oracle 10g，查看发送到数据库的确切查询

Question

I have an application from a third party that writes to the Oracle database. One component of the application returns no data given particular parameters, while the other component of the application does return data with those same parameters. Nobody has the source code to this application, but it can be seen that the database has the proper information in it.

The misbehaving component gets ORA-01403 returned from the oracle database server, which means no data found, but can be related to a syntax error, as seen by a packet sniffer I installed.

I want to see the differences in the queries that the different components of the application actually generate.

Would also like to run these queries on the command line or in some other database viewer to see what gets returned.

How can I monitor the database with a trace that actually shows the queries being made? I would also like to isolate these by IP address or source.

Using Oracle 10g Enterprise

Answer 1

I found this worked well for an AWS Oracle RDS instance. I ran the tcpdump from the linux instances connecting to the db...

tcpdump tcp port 1521 -s 0 -l -w -  | strings | perl -e '
while(<>) { chomp; next if /^[^ ]+[ ]*$/;
  if(/^(SELECT|UPDATE|DELETE|INSERT|SET|COMMIT|ROLLBACK|CREATE|DROP|ALTER)/i) {
    if (defined $q) { print "$q\n"; }
    $q=$_;
  } else {
    $_ =~ s/^[ \t]+//; $q.=" $_";
  }
}'

Hope that helps someone else.

Answer 2

IIRC, TOAD will do what you want.

Additionally, there is a free trial - http://www.quest.com/toad-for-oracle/software-downloads.aspx

There are other interesting downloads (search oracle free toad) but I can't be sure of their legitimacy.

Answer 3

If your client connects directly to the database without any middle-tier layer, then you have two pretty much straightforward options.

First of all, figure out required session's ID using v$session view, and then either find your query in v$sql / v$sql_text by its hash value (you can check description of each in the docs ), or enable session-level sql trace (1) (2) and get your queries in a plain text trace file.

If you have a middle-tier then things get slightly more complicated but only in terms of figuring out the session you need to trace. You can always enable system-wide tracing though.

Answer 4

A little late to the party but I ran into this problem and didn't want to installe something on the database server for a one off use, I wound up using wireshark; the queries were sent in plaintext and perfectly readable.