Prev: what's the internal transaction table for....
Next: dbms_session.set_context from JDBC fails mysteriously, how can I trap it ?
From: joel garry on 10 Feb 2010 14:51
On Feb 10, 6:02 am, John Hurley <johnbhur...(a)sbcglobal.net> wrote:
> On Feb 10, 6:49 am, Charles Hooper <hooperc2...(a)yahoo.com> wrote:
>
> snip
>
> > I agree with John - take a look at the number after dep= in the trace
> > file - that is indicating that it is very likely a trigger that is
> > executing these calls, but it could also be an anonymous PL/SQL
> > block.  You might try the following SQL statement to see if there is a
> > logon or startup trigger:
>
> It is a little hard to believe that someone would have a trigger in
> effect that they forgot about but ...
>

Not hard to believe at all, it's easy to forget to unwind every bit of
instrumentation turned on in the heat of a problem, especially with
multiple cooks involved. I didn't even think of a logon trigger
because I so rarely do it that way, forehead-slapping obvious now that
you guys pointed it out. There was a time I ran startup scripts to
pin stuff in the shared library too, but I haven't done that in a very
long time, either...

I'm still finding stuff in odd places from a remote developer while I
was on vacation last year. Take a complicated stack and put pressure
on to get things done, all sorts of weird happens. Then you have to
figure out what was fanned and what is necessary but named wrong.

Heck, even Oracle has delivered with trace turned on (otr, was it
7.3.2?). Oops!

jg
--
@home.com is bogus.
http://www.signonsandiego.com/news/2010/feb/10/barber-finds-fame/
From: BD on 10 Feb 2010 19:53

> It is a little hard to believe that someone would have a trigger in
> effect that they forgot about but ...

Oh, believe it.

A bit embarassing, but there you go.

Basically I had been troubleshooting a problem involving using
Replication to replicate a table with a custom datatype. Even if I was
not selecting the columns with the custom datatype in the SELECT
statement of my MV, it errored out - but *only* over a db link.

In hindsight, the cause of the issue was likely not about the db link,
but rather that the schema owner of the source table didn't own the
type definition; it was owned by another schema in the source db.

The ID which was receiving the replicated data didn't have grants on
the type definition, only on the data in the table.

Anyway. I quite honestly have no recollection of creating that trigger
- partly because of the hair-on-fire way I needed to resolve the issue
at the time, and partly because it took a long time for the symptoms
of leaving the trigger in place (trace file bloating) to become
evident. But there it is.

Or rather, there it was. ;)

Thanks, John. I was about to throw in the towel, and just delete the
install of XE and start over.

*Clearly*, I need to document things more effectively. Oi... ;)
From: John Hurley on 13 Feb 2010 08:42
On Feb 10, 7:53 pm, BD <robert.d...(a)gmail.com> wrote:

snip

> > It is a little hard to believe that someone would have a trigger in
> > effect that they forgot about but ...
>
> Oh, believe it.
>
> A bit embarassing, but there you go.

Well glad I could help ... even a blind mouse finds a piece of cheese
every once in a while right?

First  |  Prev  | 
Pages: 1 2
Prev: what's the internal transaction table for....
Next: dbms_session.set_context from JDBC fails mysteriously, how can I trap it ?