有没有办法找到使用 DB 链接访问我们的 Oracle 数据库的数据库的详细信息?Dba_db_links保存了我们数据库中用于访问其他数据库的 DB 链接的信息,但是是否有类似的表可以从中找到访问我们数据库的 DB 链接,或者是在哪里记录的?
提前致谢。
有没有办法找到使用 DB 链接访问我们的 Oracle 数据库的数据库的详细信息?Dba_db_links保存了我们数据库中用于访问其他数据库的 DB 链接的信息,但是是否有类似的表可以从中找到访问我们数据库的 DB 链接,或者是在哪里记录的?
提前致谢。
我同意贾斯汀的观点,没有办法确定所有数据库的明确列表,这些数据库具有指向给定数据库的数据库链接。
但是,可以监视活动的数据库链接。您可以使用以下查询通过数据库链接查看哪些会话以及来自哪些数据库:
-- who is querying via dblink?
-- Courtesy of Tom Kyte, via AskTom
-- this script can be used at both ends of the database link
-- to match up which session on the remote database started
-- the local transaction
-- the GTXID will match for those sessions
-- just run the script on both databases
Select /*+ ORDERED */
substr(s.ksusemnm,1,10)||'-'|| substr(s.ksusepid,1,10) "ORIGIN",
substr(g.K2GTITID_ORA,1,35) "GTXID",
substr(s.indx,1,4)||'.'|| substr(s.ksuseser,1,5) "LSESSION" ,
s2.username,
substr(
decode(bitand(ksuseidl,11),
1,'ACTIVE',
0, decode( bitand(ksuseflg,4096) , 0,'INACTIVE','CACHED'),
2,'SNIPED',
3,'SNIPED',
'KILLED'
),1,1
) "S",
substr(w.event,1,10) "WAITING"
from x$k2gte g, x$ktcxb t, x$ksuse s, v$session_wait w, v$session s2
where g.K2GTDXCB =t.ktcxbxba
and g.K2GTDSES=t.ktcxbses
and s.addr=g.K2GTDSES
and w.sid=s.indx
and s2.sid = w.sid;
希望有帮助。
你可能正在寻找这个。
第 1 步:检查 X 数据库中会话的 hash_value。select sql_hash_value from v$session where sid=&sid;
第 2 步:检查触发 SQL 的 X 数据库中会话的完整 SQL。从 v$sql 中选择 sql_fulltext 其中 hash_value=&hash_value;
第 3 步:记下 SQL 中涉及的所有数据库链接,并确定这些数据库链接的主机。select * from dba_db_links where db_link like upper('&db_link');
第 4 步:在每个主机(比如说只有一个远程主机,指向数据库 Y)和数据库 X 本身中,触发上述查询(Tom Kyte's)以收集来自远程数据库的会话的详细信息。
第 5 步:在数据库 X 中,检查感兴趣的 SID 及其对应的 GTXID。在远程主机 Y 中查找相同的 GTXID。
第 6 步:从数据库 Y 中获取此 GTXID 的会话 ID,并检查会话等待或其他详细信息。
When you create a database link in database A that points at database B, there is no notification sent to database B so there is no data dictionary table in B that will tell you that A has a link to it. As far as B is concerned, database A is simply another client that periodically opens a connection to the database.
Generally, when A wants to create a database link to B, a user will be created in B for this purpose (assuming the database link uses a fixed user rather than the current user) since you don't want the password for this account to expire regularly and you don't want the database link to be broken if a particular human leaves the company and has his or her accounts removed. You can audit connections on B, either for the particular accounts that have been created for database links or across all users, and then look through the audit logs to identify connections that are coming from servers that house other databases.