One of the database is down in streaming environment

Question

I have scenario where one of the database in (two different database) streaming environment is unavailable due to nework/link/database maintenance purpose. Since my other database is up and running and DML/DDL operations are in process how can I avoid following error
SQL> insert into test values ('eee', 'code e');
1 row created.
SQL> commit;
commit
ERROR at line 1:
ORA-02050: transaction 5.23.8870 rolled back, some remote DBs may be in-doubt
ORA-02068: following severe error from OTHER_DOWN_DATABASE
ORA-03113: end-of-file on communication channel
============================================
Can I change some parameters in DBMS_STREAMS_ADM Package or any other packages to avoid above situation

Answer 1

Thanks for the reply.
I am getting the same error even If I just do select on the table which I have for streaming
SQL> select * from test@dbtest;
select * from test@dbtest
ERROR at line 1:
ORA-02068: following severe error from DBTEST ---destination database
ORA-03113: end-of-file on communication channel.
Q- Wich database is down? Is it the source database or the destination database?
For now I am testing with keeping down destination database.
Q- If it's the source db, just stop the capture. That's all you really have to do.
A- This can be good for planned maintenance, but how about unplanned outage or sudden problem (with networks/links or all of a sudden I can not stream my data changes to destination database).
Q--The error you're describing is unclear.... Do you get that error immediately when you issue the insert and the commit? That sound very very strange to me because streams does asynchronous replication... You would not get such an error for db down from my opinion.
A-- First time, I got this error when I updated a row and then tried to commit while my destination database was down.
Q- It looks like the problem has nothing to do with streams but rather a distributed transaction problem (2pc)...
A- If it is transaction problem should I be getting similar error while selecting from destination table, see the above error