Sqoop导出至SQL Server时使用密码文件失败问题咨询

看起来你遇到的问题挺典型——同一份密码文件在Netezza上能正常工作，到SQL Server就罢工，直接传密码参数却没问题。结合你的Sqoop版本（1.4.6.2.5.3.0-37）和驱动（sqljdbc4-2.0.jar），我整理了几个排查和解决的方向：

1. 先排查密码文件的基础问题 #

权限与路径 #

• 如果密码文件在本地磁盘：务必确保文件权限是400或600（仅所有者可读），而且运行Sqoop的系统用户拥有读取权限。权限过松可能导致Sqoop拒绝读取，或者读取过程中出现异常。
• 如果密码文件在HDFS：必须用完整的HDFS路径（比如hdfs:///user/your_account/pass.txt），同时把HDFS文件权限设为400，并确保文件属于执行Sqoop任务的用户。

隐藏字符/编码问题 #

即使你说文件只有一行密码、无特殊字符，也要警惕编辑器自动添加的UTF-8 BOM（字节顺序标记）——这是个隐藏字符，SQL Server JDBC驱动对它的兼容性不如Netezza。你可以用命令检查：

xxd your_password_file.txt | head -1

如果输出开头是ef bb bf，说明存在BOM。解决方法是用纯文本编辑器（比如Notepad++）重新保存文件，选择「UTF-8无BOM」编码，或者用命令行生成：

tr -d '\n' < original_pass.txt > clean_pass.txt

2. 用eval命令缩小问题范围 #

先别着急跑export，用Sqoop的eval命令测试密码文件是否能正常连接SQL Server：

sqoop eval \
--connect "jdbc:sqlserver://abc.com:58850;databaseName=IKB_PROD;schema=dbo;" \
--username your_username \
--password-file /path/to/your_pass.txt \
--query "SELECT TOP 1 * FROM dbo.your_test_table"

如果这个命令也失败，说明问题出在连接层面，和export逻辑无关；如果成功，再回头排查export命令的其他参数。

3. 检查JDBC驱动兼容性 #

sqljdbc4-2.0.jar是比较老的驱动版本（对应SQL Server 2012），可能和Sqoop 1.4.6存在兼容性问题。建议你替换成最新的Microsoft JDBC驱动（比如mssql-jdbc-9.4.1.jre8.jar），放到Sqoop的lib目录下，再重新测试。

4. 尝试调整SQL Server连接URL参数 #

虽然直接传密码没问题，但有时候密码文件读取后的参数拼接可能触发驱动的特殊逻辑。可以尝试在连接URL中添加加密相关参数：

sqoop export \
--connect "jdbc:sqlserver://abc.com:58850;databaseName=IKB_PROD;schema=dbo;encrypt=true;trustServerCertificate=true;" \
--table your_target_table \
--password-file /path/to/your_pass.txt \
# 其他export参数...

最后补充 #

Sqoop 1.4.6对--password-file的处理是读取文件的第一行内容，但某些边缘场景下（比如文件末尾有不可见的空白字符）可能导致密码解析错误。你可以手动确认文件内容：

cat -A your_password_file.txt

如果输出末尾没有$以外的字符，说明确实没有多余换行或空白。

内容的提问来源于stack exchange，提问作者Gaurang Shah