10.2.0.1 trace uncommitted inserts

#11

On Fri, 29 Apr 2011 17:00:01 -0700, John Hurley wrote:

Quote:

The original poster does not apparently know about setting a 10046
trace. More than one person implicated in not having the ability to
figure out what is going on at least in my mind.

10046 trace has nothing to do with the problem. The original problem, at
least according to what I have read, is that the application log contains
the record of the transaction while the table doesn't. If that is a usual
3-tier application with an application server, client and a DB server,
tracing it will not be trivial as it may include many sessions that are
unrelated to the problem. If the vendor "cannot figure out what's
happening", the vendor is extremely unlikely to be using
DBMS_APPLICATION_INFO. The best bet is a trigger with an autonomous
transaction which will show what was fired and when. That is called
"debugging" and is usually done by the people who write the application.
If they are unable to do so, which is what the OP implied, then they are
not very competent, period.
Furthermore, your sanctimonious "I'm holier than thou" attitude is
beginning to bore the heck out of me, so I ignore majority of your posts.
You can shove your crystal ball where the sun doesn't shine.

--
http://mgogala.byethost5.com

#12

On Apr 28, 4:08*pm, Tiago <diariodastril... (AT) gmail (DOT) com> wrote:

Quote:

Hi,

* I have an application written in .net, I have only the .exe, not the
source. It keeps processing data from an external source and inserting
on a table, but sometimes I can't see the data on the table. Sometimes
it inserts, sometimes doesn't. Vendor is taking too long to figure
that out, since the message that get inserted look like exactly like
the one that doesn't

I suspect it is trying to commit but something
wrong happens. App log doesn't show any error, external data source
says it sent the data correctly, App log says it received, but nothing
is inserted.

Is there a way to trace uncommited inserts? I would try to check if
the insert is happening at all, perhaps the App log isn't catching
something that could be a big error...

Thanks!

-- Tiago

Tiago, I think John's recommendation to use the standard Oracle trace
feature is a good one. Every insert will be caugth by trace committed
or not. The commits will also be caught by the trace though you will
need to scan the raw trace file to see statements.

Poor error handling often results in problems like you mentioned
especially when combined with the programmer taking control of the
transaction in the code instead of committing after every DML
statement execution which I believe is the normal .net and jodbc for
that matter defaults. There are naturally other potential problem
causes incudling bugs in the exact version of the framework being
used.

HTH -- Mark D Powell --

#13

On Sat, 30 Apr 2011 07:16:36 -0700, Mark D Powell wrote:

Quote:

Tiago, I think John's recommendation to use the standard Oracle trace
feature is a good one. Every insert will be caugth by trace committed
or not. The commits will also be caught by the trace though you will
need to scan the raw trace file to see statements.

Of course, in case of the 3-tier application, it will be a joy to read
the traces from all the server processes, especially if the application
doesn't use DBMS_APPLICATION_INFO and launches a 100 or so processes when
it is started.

--
http://mgogala.byethost5.com

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

10.2.0.1 trace uncommitted inserts

comp.databases.oracle.server comp.databases.oracle.server

Re: 10.2.0.1 trace uncommitted inserts - 04-29-2011 , 11:10 PM

Re: 10.2.0.1 trace uncommitted inserts - 04-30-2011 , 09:16 AM

Re: 10.2.0.1 trace uncommitted inserts - 04-30-2011 , 12:14 PM