+ Reply to Thread
Results 1 to 3 of 3

Re: 10.2.0.1 trace uncommitted inserts

  1. Re: 10.2.0.1 trace uncommitted inserts

    On Apr 28, 4:08*pm, Tiago 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 --

  2. Re: 10.2.0.1 trace uncommitted inserts

    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

  3. Re: 10.2.0.1 trace uncommitted inserts

    On Apr 30, 7:16*am, Mark D Powell wrote:
    > On Apr 28, 4:08*pm, Tiago 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.

+ Reply to Thread