dblink提示用户名密码不正确
前提
低版本数据库（11.2.0.2）创建访问高版本数据库（12.2.0.1）的dblink提示用户名密码错误
现象
错误1：
> 第 1 行出现错误:ORA-28040: No matching authentication protocol
ORA-02063: 紧接着 line (起自 N****M)
解决方法：修改sqlnet配置文件（参考下文）
错误2：
第 1 行出现错误:
ORA-01017: invalid username/password; logon denied
ORA-02063: 紧接着 line (起自 N****E)
解决方法
第一步：12c数据库服务器上sqlnet.ora参数修改
$ORACLE_HOME/network/admin/sqlnet.ora文件(/u01/app/oracle/product/12.2.0/dbhome_1/network/admin)
增加如下内容
SQLNET.ALLOWED_LOGON_VERSION_SERVER=8
SQLNET.ALLOWED_LOGON_VERSION_CLIENT=8
第二步：检查对应用户的password_version是否有10G，并重新设置连接dblink的用户的密码
select username,password_versions from dba_users where username='TEST';
alter user TEST identified by "123321";
第三步：测试连接成功
补充测试：
低版本数据库（11.2.0.3及以上版本）连接12c数据库的dblink不会出现上述的问题
12c数据库信息如下
在11.2.0.3版本数据库创建dblink，并测试连接
在11.2.0.4版本数据库创建dblink，并测试连接
原理解释
参数说明
SQLNET.ALLOWED_LOGON_VERSION_CLIENT
这个参数是12C新引进的参数。它表示Cp在向Sp发送认证（authentication）申请时，所使用的最低版本的认证协议。注意此处的认证协议版本并不等同于Oracle Database的版本。那不同的认证协议版本主要区别在哪儿呢？除了协议语义上的区别，在我看来，最重要的区别在于不同认证协议的版本对应着不同的database version，而不同的database version则可能使用不同的hash算法对密码进行加密。不同的hash算法就是不同的password_version，下图为dba_users表的表结构
Oracle在存储每个account的密码时，并非是明文存储，而是会将明文进行哈希加密存储，哈希加密算法即为该密码的version，即password_version。从上图Figure 7中可知，password_version实际上表示是同版本（并非完全一致，见最后的附表）的database 所提供的hash算法，例如password_version 10g就表示database 10g所提供的hash算法。如果Oracle所有的新版本都只使用新版本所特有的hash算法，那么一些较早的客户端因为还没有这些hash算法，就没法通过hash算法得到hash值，也就没法让服务器去验证这些hash值。为了解决兼容性的问题，Oracle会同时用多种hash算法（即password_version）对密码进行运算，并将多个运算结果均保留下来。在低版本客户端访问高版本的服务器时，低版本的客户端可以通报自己使用的认证协议以及使用该协议对应的hash算法所得到的密码hash值，服务器根据认证协议去查看是否存储了该协议对应的hash算法的hash值，如果存在，就比对两个hash值是否一致；如果不存在或两个hash值不一致，就报错。
SQLNET.ALLOWED_LOGON_VERSION_SERVER
关于这个参数的作用，它介绍了为这个参数设置不同的值所带来的影响，主要是对PASSWORD_VERSIONS的影响。最后附带了一张表，详细了列出了SQLNET.ALLOWED_LOGON_VERSION_SERVER设置不同值，所对应的password_versions。也说明了如果要与设置成当前值的12C数据库进行密码认证，所支持的client version。从上图可以看出，即使SQLNET.ALLOWED_LOGON_VERSION_SERVER设置为8，但生成的最低版本的password version也是10G。因此也说明，8I，9I的客户端因为没法理解10G的哈希函数，也就没法完成登陆认证。关于客户端到服务器端相互之间的兼容性如下表(下图来源于网络)：
认证协议版本、database版本与password版本之间的关系
参考链接：
https://www.cnblogs.com/6yuhang/p/7600929.html
http://www.cnblogs.com/lhrbest/p/6219687.html