session blocked after network failure [message #195816] |
Mon, 02 October 2006 10:30 |
sbielmann
Messages: 2 Registered: October 2006
|
Junior Member |
|
|
I have a boring problem with my advanced replication setup
for oracle 10g. One master, multiple clients with
materialized views. There are daemons writing data into
the client databases which will then be written to the
master via the replication user of these materialized views.
Some daemons may directly write on the master, thus sequences
have been setup with gaps to work correctly.
One of the tests I do is to unplug the network from the
clients, plug it back after a while to check if the setup
is really working and synchronizing after this kind of failure.
Doing so, sometimes, not every time though, the materialized
view user does not unlock the views he was working on at the
time of the network failure, so it seems. And it wont release
it anymore, for hours and hours, until I shut the whole
oracle instance down and restart it.
To this point I have retrieved the following informations:
-dba_jobs, not broken but the refresh job for the
materialized views has failures and a manual refresh takes
endlessly time, until I interrupt it.
-v$session_wait indicates that the materialized view user is
waiting for data from the dblink since the network failure
-v$transaction indicates that there is an open transaction
since the network failure for that user
-via v$locked_object, v$session and dba_objects I see that
that user is having a lock on some materialzed views and
not releasing them, other sessions/users are waiting to get
a lock to them
-dba_locks tells it is blocking these materialized views
-killing the session of that user will report that oracle
has marked the session for kill, but wont kill it for real
-used_ublk from v$transaction remained the same
Has anyone experienced a similar problem, or an idea where
to look for to get more information about this issue and
its resolution.
Thanks in advance
Stephan
|
|
|
|
|
Re: session blocked after network failure [message #210302 is a reply to message #210264] |
Wed, 20 December 2006 04:02 |
sbielmann
Messages: 2 Registered: October 2006
|
Junior Member |
|
|
Thanks for the tip Srikanth,
I found that out long time ago, however neither
does it solve the problem, nor is it applicable
in my environment. Above all, killing that job
may lead to other failures. In fact rebooting
of the whole system is until this moment the
only option, however not at all what is needed
in a production environment.
|
|
|