[20180529]克隆数据库与dblinks注意.txt

  1. 云栖社区>
  2. 博客>
  3. 正文

[20180529]克隆数据库与dblinks注意.txt

lfreeali 2018-05-30 08:52:05 浏览949
展开阅读全文

[20180529]克隆数据库与dblinks注意.txt

--//在做数据库克隆,一般情况下给开发做测试,要注意一个细节问题,就是数据库内建立的dblink.
--//有可能导致一些异常情况,特别是国内环境生产数据库与测试数据库没有分开的情况下,很有可能导致
--//无意中窜改生产系统的数据.

--//还是通过例子说明问题:
1.环境:
SCOTT@book> @ ver1
PORT_STRING                    VERSION        BANNER
------------------------------ -------------- --------------------------------------------------------------------------------
x86_64/Linux 2.4.xx            11.2.0.4.0     Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production

--//说明一下,现在许多dba或者开发习惯使用ezconnect模式配置dblink,这样的好处不需要修改tnsnames.ora文件.
--//特别在rac环境这种优势更加明显.因为rac要修改多台机器的配置文件.但是正是这样,在克隆时也把dblink的配置
--//带到克隆环境,如果你开发与生产环境没有很好的隔离,很可能在克隆数据库执行dml语句时,出发一些job做更新
--//别的数据库的操作....
--//我先测试其它情况:

CREATE PUBLIC DATABASE LINK TEST
CONNECT TO SCOTT
IDENTIFIED BY book
USING 'test';

--//在tnsnames.ora配置如下:
TEST =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.100.40)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = bookdg)
    )
  )

SCOTT@book> select sysdate from dual@test;
SYSDATE
-------------------
2018-05-30 08:31:52

SCOTT@book> select INSTANCE_NAME from v$instance@test;
INSTANCE_NAME
----------------
bookdg

--//说明一下:IP=192.168.100.40是我测试数据库的dataguard.

2.如果在dg上执行:
SCOTT@bookdg> select INSTANCE_NAME from v$instance@test;
--//挂起,因为在dg上没有配置test的tns别名.假设配置如下:
TEST =
  (DESCRIPTION =
    (ADDRESS = (PROTOCOL = TCP)(HOST = 192.168.100.78)(PORT = 1521))
    (CONNECT_DATA =
      (SERVER = DEDICATED)
      (SERVICE_NAME = book)
    )
  )

SCOTT@bookdg> select INSTANCE_NAME from v$instance@test;
INSTANCE_NAME
----------------
book

--//这样你克隆的机器实际上访问不同的数据库.而且有一些还与环境变量TNS_ADMIN有关.不再测试.
--//另外说明一下,我在dg上如果访问的tns的别名的数据库是10g的,会出现如下错误.
SCOTT@bookdg> select sysdate from dual@test;
select sysdate from dual@test
                         *
ERROR at line 1:
ORA-16000: database open for read-only access

--//因为dg只能以read only打开.访问11g的数据库没有问题.
--//另外如果sql语句出现2个访问dblink的情况,也会报错.参考链接:
http://blog.itpub.net/267265/viewspace-2138879/=>[20170511]DBLINK跨库查询遇到ORA-16000

3.继续测试:
--//如果你使用ezconnect方式配置,这样的好处不需要修改tnsnames.ora文件.
--//特别在rac环境这种优势更加明显.因为rac要修改多台机器的配置文件.但是正是这样,在克隆时也把dblink的配置
--//带到克隆环境,如果你开发与生产环境没有很好的隔离,很可能在克隆数据库执行dml语句时,出发一些job做更新
--//别的数据库的操作....

4.总之:
--//在做克隆时要注意这个细节,最好在参数文件设置job_queue_processes=0,open_links,open_links_per_instance=0
--//确定那些dblink是否需要或者改正.不需要的删除,尤其要重视ezconnect配置的dblink.避免出现意外.
--//还有1个习惯设置开发与生产系统的连接用户口令不一样,也一定程度减少这样的错误.

网友评论

登录后评论
0/500
评论
lfreeali
+ 关注