[Reprint] Oracle database link to query the transaction will open it?

Oracle database link to query the transaction will open it?

https://www.cnblogs.com/kerrycode/p/10148050.html

 

About oracle database link, use the database link related query whether it will open a transaction? We know that in a database a simple SELECT query does not produce Affairs (select for update will produce affairs). Test as follows:

 

 

 

 

We first prepared the test environment, create a database link: LINK_NODEFINE_TEST, and then we start the test

 

CREATE PUBLIC DATABASE LINK LINK_NODEFINE_TEST
CONNECT TO TEST IDENTIFIED BY "t123$%^" 
USING '(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 10.20.57.24)(PORT = 1521))
    )
    (CONNECT_DATA =
      (SERVICE_NAME = gsp.localdomain)
    )
  )';

 

 

Here begin the demo to see if database link will open a transaction related queries:

 

SQL> show user;
USER is "SYS"
SQL> select userenv('sid') from dual;
 
USERENV('SID')
--------------
           939
 
SQL> select xidusn, xidslot, xidsqn  
  2  from v$transaction, v$session  
  3  where saddr=ses_addr;
 
no rows selected
 
SQL> select * from kerry@link_nodefine_test;
 
        ID NAME
---------- --------------------------------
       100 kerry
 
SQL> select xidusn, xidslot, xidsqn  
  2  from v$transaction, v$session  
  3  where saddr=ses_addr;
 
    XIDUSN XIDSLOT XIDSQN
---------- ---------- ----------
         3         14    4122050
 
SQL> alter session close database link link_nodefine_test;
ERROR:
ORA-02080: database link is in use
 
 
SQL> commit; - must first commit, you can close links
 
Commit complete.
 
SQL> alter session close database link link_nodefine_test;
 
Session altered.

 

Let's create an account TEST, life cycle remote sessions in database testing and certification database link points to a simple test, you will find that even a simple query (containing database link), generates a session on the remote database. And, if not executed alter session close database link xxx close the corresponding database link, it does not destroy the session, but it becomes INACTVIE state. It will be to clean up the database until it is triggered after a TCP keepalive mechanisms.

 

 

 

 

Once you perform a database link related queries, the database instance in this test server remote database (10.20.57.24), it will generate a corresponding session, and only execute on the primary database , " the alter session close database link link_nodefine_test", the corresponding session will be destroyed (of course, clean up the database will be triggered after the TCP keepalive mechanisms). Interested can self-test.

 

SQL> select count(*) from v$session where username='TEST';
 
  COUNT(*)
----------
         1
 
SQL> select count(*) from v$session where username='TEST';
 
  COUNT(*)
----------
         0
 
SQL> 

 

So the question is, if I use several times in the conversation among the select * from kerry @ link_nodefine_test Such statements include database link, will generate more than one session 10.20.57.24 do? Or this database link associated with the session will reuse it? Here we test to test:

 

As shown below, using the same session database link among the multiple queries, multiple sessions will not generate 10.20.57.24. However, if a plurality of different sessions database link link_nodefine_test are used, then a plurality of sessions is generated in (10.20.57.24) .

 

 

 

 

 

So if in the same session, using different database link, but both use the same account database link, pointing to the same server, whether this also share a conversation it? The answer is no, but will create a new session. Test as shown below

 

CREATE PUBLIC DATABASE LINK LINK_DEDIATED_TEST
CONNECT TO TEST IDENTIFIED BY "t123$%^" 
USING '(DESCRIPTION =
    (ADDRESS_LIST =
      (ADDRESS = (PROTOCOL = TCP)(HOST = 10.20.57.24)(PORT = 1521))
    )
    (CONNECT_DATA =
       (SERVER = DEDICATED)
      (SERVICE_NAME = gsp.localdomain)
    )
  )';

 

 

 

 

Inquire About dblink Why the affairs of the principles of analysis, refer to the official documentation Transaction Processing in a Distributed System

 

 

Two-Phase Commit Mechanism

 

A database must guarantee that all statements in a transaction, distributed or non-distributed, either commit or roll back as a unit. The effects of an ongoing transaction should be invisible to all other transactions at all nodes; this transparency should be true for transactions that include any type of operation, including queries,updates, or remote procedure calls.

 

The general mechanisms of transaction control in a non-distributed database are discussed in the Oracle Database Concepts. In a distributed database, the database must coordinate transaction control with the same characteristics over a network and maintain data consistency, even if a network or system failure occurs.

The database two-phase commit mechanism guarantees that all database servers participating in a distributed transaction either all commit or all roll back the statements in the transaction. A two-phase commit mechanism also protects implicit DML operations performed by integrity constraints, remote procedure calls, and triggers.

 

 

to sum up:

 

Oracle database using dblink related query will produce a transaction, if there are a large number of sessions using dblink, it will generate a lot of conversation in the remote database, the number of connections sometimes consumed will be very substantial. For dblink session in the remote database, you must first commit in the current session of the local database, then alter session close database link xxx, close dblink, if you do not perform these operations, can only rely on DCD or Tcp KeepLive database trigger mechanism for destroying session.

 

 

 

References:

 

 

https://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:393468893370

http://blog.itpub.net/267265/viewspace-2123710/

https://docs.oracle.com/cd/B28359_01/server.111/b28310/ds_concepts004.htm#ADMIN12120

 

Guess you like

Origin www.cnblogs.com/jinanxiaolaohu/p/12321853.html