Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.databases.oracle.server > #547 > unrolled thread

10.2.0.1 trace uncommitted inserts

Back to article view | Back to comp.databases.oracle.server

Contents

  10.2.0.1 trace uncommitted inserts Tiago <diariodastrilhas@gmail.com> - 2011-04-28 13:08 -0700
    Re: 10.2.0.1 trace uncommitted inserts John Hurley <hurleyjohnb@yahoo.com> - 2011-04-28 14:39 -0700
    Re: 10.2.0.1 trace uncommitted inserts Mladen Gogala <no@email.here.invalid> - 2011-04-29 16:30 +0000
      Re: 10.2.0.1 trace uncommitted inserts John Hurley <hurleyjohnb@yahoo.com> - 2011-04-29 12:47 -0700
        Re: 10.2.0.1 trace uncommitted inserts ddf <oratune@msn.com> - 2011-04-29 13:15 -0700
          Re: 10.2.0.1 trace uncommitted inserts John Hurley <hurleyjohnb@yahoo.com> - 2011-04-29 15:25 -0700
          Re: 10.2.0.1 trace uncommitted inserts John Hurley <hurleyjohnb@yahoo.com> - 2011-04-29 15:29 -0700
            Re: 10.2.0.1 trace uncommitted inserts Mladen Gogala <no@email.here.invalid> - 2011-04-29 22:45 +0000
            Re: 10.2.0.1 trace uncommitted inserts ddf <oratune@msn.com> - 2011-04-29 16:06 -0700
              Re: 10.2.0.1 trace uncommitted inserts John Hurley <hurleyjohnb@yahoo.com> - 2011-04-29 17:00 -0700
                Re: 10.2.0.1 trace uncommitted inserts Mladen Gogala <gogala.mladen@gmail.com> - 2011-04-30 04:10 +0000
    Re: 10.2.0.1 trace uncommitted inserts Mark D Powell <Mark.Powell2@hp.com> - 2011-04-30 07:16 -0700
      Re: 10.2.0.1 trace uncommitted inserts Mladen Gogala <gogala.mladen@gmail.com> - 2011-04-30 17:14 +0000
      Re: 10.2.0.1 trace uncommitted inserts joel garry <joel-garry@home.com> - 2011-05-02 09:38 -0700

#547 — 10.2.0.1 trace uncommitted inserts

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

[toc] | [next] | [standalone]

#548

On Apr 28, 4:08 pm, Tiago <diariodastril...@gmail.com> wrote:
> 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

If you are really running on 10.2.0.1 ( not 10.2.0.4 or 10.2.0.5 )
then some really bad things could be happening with a ton of unapplied
oracle maintenance.

An Oracle 10046 trace is the usual recommended definitive way of
tracing what is going on with an application.

Can you work with a dba resource to get a trace done for you?

[toc] | [prev] | [next] | [standalone]

#553

On Thu, 28 Apr 2011 13:08:02 -0700, Tiago wrote:

>  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.

Now this looks like an intelligent design! There are entities called 
"triggers" which can be made to fire on insert. Also, the vendor looks 
like a very competent application producer. Can you reveal us the name of 
that brilliantly competent software company? The other users need to be 
warned.



-- 
http://mgogala.byethost5.com

[toc] | [prev] | [next] | [standalone]

#560

Mladen:

# Now this looks like an intelligent design! There are entities called
"triggers" which can be made to fire on insert.

...

So you have already been able to look inside from the little material
supplied by the OP and guess that triggers are involved?  Your crystal
ball must be working better than mine today.

[toc] | [prev] | [next] | [standalone]

#561

On Apr 29, 12:47 pm, John Hurley <hurleyjo...@yahoo.com> wrote:
> Mladen:
>
> # Now this looks like an intelligent design! There are entities called
> "triggers" which can be made to fire on insert.
>
> ...
>
> So you have already been able to look inside from the little material
> supplied by the OP and guess that triggers are involved?  Your crystal
> ball must be working better than mine today.

That is not what Mladen said or implied.  The intent here is to
suggest that the OP possibly create a trigger to capture insert
transactions into a separate table, with other information such as who
did the insert and when, to track what is or isn't  happening.  There
was no mention that the venedor is using triggers.


David Fitzjarrell

[toc] | [prev] | [next] | [standalone]

#564

On Apr 29, 4:15 pm, ddf <orat...@msn.com> wrote:
> On Apr 29, 12:47 pm, John Hurley <hurleyjo...@yahoo.com> wrote:
>
> > Mladen:
>
> > # Now this looks like an intelligent design! There are entities called
> > "triggers" which can be made to fire on insert.
>
> > ...
>
> > So you have already been able to look inside from the little material
> > supplied by the OP and guess that triggers are involved?  Your crystal
> > ball must be working better than mine today.
>
> That is not what Mladen said or implied.  The intent here is to
> suggest that the OP possibly create a trigger to capture insert
> transactions into a separate table, with other information such as who
> did the insert and when, to track what is or isn't  happening.  There
> was no mention that the venedor is using triggers.
>
> David Fitzjarrell

[toc] | [prev] | [next] | [standalone]

#565

David:

# That is not what Mladen said or implied.

So you are Mladen are twins that understand exactly what the other was
trying to convey in a newsgroup posting?

I did not realize that ...

# The intent here is to suggest that the OP possibly create a trigger
to capture insert  transactions into a separate table, with other
information such as who did the insert and when, to track what is or
isn't  happening.

That's such a better idea than getting a 10046 trace initially eh?

# There was no mention that the venedor is using triggers.

Try reading the next several lines of Mladens reply that I left out a
couple of times.  Do the shampoo thing ( rinse and repeat ) ...

[toc] | [prev] | [next] | [standalone]

#566

On Fri, 29 Apr 2011 15:29:10 -0700, John Hurley wrote:

> So you are Mladen are twins that understand exactly what the other was
> trying to convey in a newsgroup posting?

You're beginning to bore me.



-- 
http://mgogala.byethost5.com

[toc] | [prev] | [next] | [standalone]

#567

On Apr 29, 3:29 pm, John Hurley <hurleyjo...@yahoo.com> wrote:
> David:
>
> # That is not what Mladen said or implied.
>
> So you are Mladen are twins that understand exactly what the other was
> trying to convey in a newsgroup posting?
>
> I did not realize that ...
>
> # The intent here is to suggest that the OP possibly create a trigger
> to capture insert  transactions into a separate table, with other
> information such as who did the insert and when, to track what is or
> isn't  happening.
>
> That's such a better idea than getting a 10046 trace initially eh?
>
> # There was no mention that the venedor is using triggers.
>
> Try reading the next several lines of Mladens reply that I left out a
> couple of times.  Do the shampoo thing ( rinse and repeat ) ...

I have, but apparently you didn't comprehend the text.  Read the post
prior to Mladen's stating that the vendor can't figure out why this
isn't working; any vendor that can't figure out their own product is
suspect in my book, too.


David Fitzjarrell

[toc] | [prev] | [next] | [standalone]

#570

David:

# I have, but apparently you didn't comprehend the text.  Read the
post prior to Mladen's stating that the vendor can't figure out why
this isn't working; any vendor that can't figure out their own product
is suspect in my book, too.

We have one posting from someone "claims" the vendor cannot figure out
what is going on.  Sometimes vendors are provided incomplete
information believe it or not.  Sometimes vendors work with people
running applications on unsupported environments or old versions of
applications believe it or not.  Running critical applications on
unpatched Oracle base releases is not always a good idea believe it or
not.

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.

Based on one limited posting jumping on the bandwagon claiming the
vendor cannot figure out what is going on seems a little hasty.

Recommending that people consider implementing triggers to help debug
a vendors application given the current amount of information in this
thread also seems a little hasty.

Just my opinion ...

[toc] | [prev] | [next] | [standalone]

#572

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

> 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

[toc] | [prev] | [next] | [standalone]

#575

On Apr 28, 4:08 pm, Tiago <diariodastril...@gmail.com> wrote:
> 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 --

[toc] | [prev] | [next] | [standalone]

#576

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

> 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

[toc] | [prev] | [next] | [standalone]

#583

On Apr 30, 7:16 am, Mark D Powell <Mark.Powe...@hp.com> wrote:
> On Apr 28, 4:08 pm, Tiago <diariodastril...@gmail.com> wrote:
>
>
>
> > 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.

Tiago, you might let us know your level of comfort with Oracle.  The
trace files can answer it, but that can be quite deep if you aren't
familiar with them.  There are plenty of resources on the web to
understand them, as well as people willing to help you read them, but
it can be daunting and time consuming.  There's a less appropriate
attack for this type of problem, using the logmining tool to see what
dml has happened to infer what the program has done, which may become
more appropriate simply because it is easier, and may also show a
pattern when you look at many times, so you can spot what conditions
make it happen.  Debugging with triggering basically allows you to
focus on the global pattern, and might lead directly to which
conditions.

I've heard from dotnet programmers that there are decent disassemblers
out there to figure out exe's and dll's, but don't know much about it,
other than you'd need an expert in those things, and sometimes it is
worth it to bypass the vendor.

Sometimes doing the tracing or other debugging can give a vendor a
clue to fix it, too.  Front line vendor support may simply not be good
enough to tell the backend programming staff what is wrong.  I've run
into a number of situations where I've given stuff to vendors and they
just pass it along to the back end, who are happy to have a customer
who understands the issues, in some cases they've raised similar
concerns but haven't been allowed to deal with them by management with
a rigid support bug-proving process.  And sometimes running through
the processes with the vendor support teaches them something useful.

>
> 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.

My first thoughts too, improperly handled error stacking and/or
version specific bugs.

>
> HTH -- Mark D Powell --

jg
--
@home.com is bogus.
During the webinar, you will also learn how Palo Alto Networks offers
the best price / performance of all firewall vendors, while earning
only one of two "recommend" ratings from NSS Labs.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.databases.oracle.server

csiph-web