简介这是一份面向 Oracle 开发人员与数据库管理员的免费图形化管理工具包对应 SQL Developer 4.0.3.16.84-x64 版本支持在 64 位系统中快速建立数据库连接编写与调试 SQL/PL/SQL浏览和编辑表数据设计数据模型并利用迁移工具导入其他数据库数据还可通过 AWR 报告和 SQL 调优顾问分析性能瓶颈解决开发、测试和生产环境中的常见管理问题。压缩包共 2000 个文件以 jar 程序库、xml 配置、sql 样例脚本、xslt 转换资源、exe 与 dll 运行组件为主体辅以少量说明文档和图标素材整体大小约 312.28MB。目前已有 770 人学习下载适合数据库初学者快速上手也适合有经验的开发者作为离线安装与统一版本管理的基础包。解压即可得到完整的程序目录内置大量示例 SQL、地区时区配置等辅助文件既能用于功能评估也可作为团队离线部署的备用资源。1. 这个 Oracle SQL Developer 4.0.3.16.84 x64解决的是你连不上数据库的第一层焦虑但凡你干过几年 Oracle 数据库的维护一定遇到过这种场景生产环境报错PL/SQL 那块 IDE 装了三次都弹不出登录框命令行里 sqlplus 能用但看执行计划费劲团队成员之间传一个连接串还要靠截图。Oracle 官方出品的 SQL Developer 正好卡在这个位置上——它是 Oracle 数据库最直接的图形化客户端自带 SQL 工作表、执行计划、导出导入和 DBA 面板不需要额外装完整的 Oracle 客户端就能通过 JDBC Thin 直连实例。这次拆的是 sqldeveloper 4.0.3.16.84 x64 这个版本适合手头有 64 位 JDK、机器还是老一点配置的从业者装完后你至少能在同一个界面里完成连接管理、写 SQL、看执行计划、导出数据四件事解决新人摸不着监听配置、老手懒得敲 sqlplus 的日常尴尬。2. 安装前置64 位软件配 64 位 JDK这一步最容易翻车2.1 先确认系统里有没有可用的 64 位 JDK我装这个版本时踩过最无厘头的一个坑是电脑里装了 32 位和 64 位两套 JDKSQL Developer 启动时找到的是 32 位那个结果界面起不来或者起来后动不动就报Unable to launch the Java Virtual Machine。SQL Developer 从 4.0 开始对 JDK 位数非常敏感x64 的安装包必须配 x64 的 JDK版本上建议 1.8 以上。先打开命令行确认java -version如果输出类似下面这样说明你这个终端里拿到的就是 64 位java version 1.8.0_211 Java(TM) SE Runtime Environment (build 1.8.0_211-b12) Java HotSpot(TM) 64-Bit Server VM (build 25.211-b12, mixed mode)注意看第三行的64-Bit字样。如果只显示Java HotSpot(TM) Client VM或者根本没有64-Bit那你的 PATH 里大概率是 32 位 JDK 在捣乱。我一般这样处理把 64 位 JDK 的安装路径完整记下来比如C:\Program Files\Java\jdk1.8.0_211然后直接设置成系统环境变量 JAVA_HOME。set JAVA_HOMEC:\Program Files\Java\jdk1.8.0_211 set PATH%JAVA_HOME%\bin;%PATH%设置完重新开一个命令行窗口再跑一次java -version。这一步别偷懒因为 SQL Developer 4.0.3.16.84 读取 JAVA_HOME 的优先级高于系统 PATH 里碰巧找到的那个 java.exe你 PATH 里指到 32 位老 JDK 的话后面所有功能都会跟着出问题。另一个常见现象是明明装了 JDK 但启动时提示找不到 JAVA_HOME这时候要去检查环境变量里是不是带上了结尾的反斜杠或分号变量值里不要画蛇添足。2.2 安装路径与目录结构别把软件装在中文目录SQL Developer 4.0.3.16.84 的安装包一般是个压缩包解压后直接得到sqldeveloper文件夹。它不需要写注册表也不需要运行 install 程序这种绿色化设计方便是真方便但很多人直接右键解压到了带中文名称的目录比如D:\工具\sqldeveloper后面连接 Oracle 时导入证书、读取配置都会出怪问题。我一般建议放纯英文路径D:\app\sqldeveloper\解压完成后目录结构大概是这样的sqldeveloper/ ├── sqldeveloper/ │ ├── bin/ │ │ └── sqldeveloper.exe │ ├── lib/ │ └── jdbc/ ├── jdk/ └── readme.html注意sqldeveloper\sqldeveloper\bin\sqldeveloper.exe这个路径很多资料里直接说点 bin 下的 exe但实际解压后中间还有一层目录。首次双击 exe 后程序会在用户目录下生成配置文件夹默认路径是C:\Users\用户名\.sqldeveloper\里面有按版本号区分的子目录比如system4.0.3.16.84。这个目录里保存了你所有的连接配置、窗口布局和日志备份连接环境时只需要打包这个目录即可这是很多老手不说的细节。2.3 首次启动sqldeveloper.conf 里要改的三个参数如果双击启动后界面一直卡在初始画面或者弹出一个空白窗口大概率是配置文件里几个参数不对。sqldeveloper\sqldeveloper\bin\sqldeveloper.conf是这个工具的启动总闸我每次装完都会先开这个文件检查以下三项# 强制指定 JDK避免 PATH 里多个 Java 互相干扰 SetJavaHome ../../jdk # JVM 启动参数4.0.3 版本 2G 以内够用 AddVMOption -Xmx1G # 界面语言如果不设置部分系统会出现英文菜单 AddVMOption -Duser.languagezh逐行说明一下SetJavaHome指向的是相对路径../../jdk对应刚才目录结构里的sqldeveloper/jdk如果这个版本没自带 JDK就要改成你的 64 位 JDK 绝对路径-Xmx1G是最大堆内存如果你同时开多个连接、还要跑大查询导出可以调大到 2G但别盲目给 4G老版本 JVM 在 Windows 上内存分配过大会出现奇怪的闪烁问题-Duser.languagezh是强制中文界面不设置的话 Win10 英文版系统里菜单就是英文某些汉化不完全的地方还会显示成半中半英。配置文件改完后重新启动看到主界面左侧出现「连接」树、右侧出现 SQL 工作表区域说明环境已经就绪。这个阶段不用急着建连接先确认菜单栏「工具 → 首选项」能正常打开能打开就代表 GUI 初始化完整后面连接数据库只是填参数的事。3. 连接 Oracle监听、TNS 与连接名的三层关系3.1 通过 SQL Developer 新建连接的第一步环境就绪后第一件事是建一个能用的数据库连接。SQL Developer 里连接的本质是 JDBC URL只是它把这些参数封装成了表单。点左上角绿色「」号进入新建连接界面需要填这几项连接名: 随意起建议带业务含义 用户名: scott 口令: tiger 主机名: 127.0.0.1 端口: 1521 服务名: orcl - [ ] 保存密码 - ( ) 基本 ( ) TNS ( ) 自定义 JDBC我建议连接名写成「业务_库名_用途」的结构比如bossdb_dev_readonly因为一个开发者手头可能同时维护十几个连接后面重装或迁移配置时有个清晰名字能省大量时间。主机名和端口这两个字段决定了你能不能找到数据库监听的入口很多第一次连的人会在这里填错比如填了数据库服务器的机器名但 DNS 解析不了或者端口填了 1522 而监听实际在 1521。验证方法是先别点连接用命令行确认网络和监听状态tnsping 127.0.0.1:1521如果返回OK字样说明数据库监听在接收请求。此时回到 SQL Developer 点「测试」按钮正常会提示「状态: 成功」。失败的话页面会直接抛出错误代码后面第四章里逐个排查。3.2 直连与 TNS 别名两种连接方式之间怎么选新建连接界面里的连接类型有三种实际常用的是「基本」和「TNS」。「基本」方式需要你手动填主机名、端口、服务名适合直连场景尤其在数据库没有配置 TNS 别名或者你不想依赖tnsnames.ora文件时最省事。「TNS」方式则是从本地或远程读取 TNS 别名列表下拉框里选一个就行适合公司内网维护的规范环境。我维护过的一台测试机上DBA 把几十个库的别名都维护在tnsnames.ora里这种情况下用 TNS 方式确实方便但如果你自己学习或者搭临时环境我建议统一用「基本」方式。原因很简单TNS 方式在 SQL Developer 4.0.3.16.84 里有个隐藏坑——它读取的tnsnames.ora路径取决于TNS_ADMIN环境变量而这个变量没配置时不同机器上解析出来的路径完全不同。有时候你明明在$ORACLE_HOME\network\admin下放了文件程序却去%APPDATA%目录下找找了半天找不到就直接列一个空列表。我给新手一个对比表可以根据自己情况选连接方式适合场景依赖条件缺点基本学习、临时直连、非标准端口无每次要手填主机和端口TNS公司内网多库环境tnsnames.ora路径正确路径解析容易翻车自定义 JDBC需要自定义 URL 参数熟悉 JDBC 语法门槛高一般用不上如果你一定要用 TNS 方式可以在系统环境变量里手动加一个TNS_ADMIN指到你存放tnsnames.ora的那个目录然后在 SQL Developer 里重启一次下拉框里才会出现正确的别名列表。3.3 用 SQL 工作表验证连接查字典表与用户权限连接成功后左侧树能看到表、视图、存储过程等对象但这只说明 JDBC 连上了不代表你真正具备查询能力。我每次新环境接完连接会先打开 SQL 工作表跑三条查询快速验证权限和基础环境-- 验证当前用户和默认表空间 SELECT USER, DEFAULT_TABLESPACE FROM USER_USERS; -- 验证会话字符集NLS 参数影响中文存取 SELECT * FROM NLS_SESSION_PARAMETERS WHERE PARAMETER NLS_CHARACTERSET; -- 验证能读到数据字典说明基础 SELECT 权限可用 SELECT COUNT(*) FROM ALL_TABLES WHERE OWNER SCOTT;第一条查询的结果如果出现用户名说明认证没问题第二条里的NLS_CHARACTERSET如果是AL32UTF8中文数据读写不会乱码如果是ZHS16GBK也正常关键在于和数据库服务端保持一致第三条如果返回 0说明用户名没权限读别的 schema 的表这不代表连接有问题只能说明权限边界窄。日常操作时SQL 工作表的执行按钮是那个绿色播放箭头也可以按CtrlEnter只执行当前光标所在的语句避免选中了整个脚本导致批量执行出奇怪错误。4. 避坑4.0.3.16.84 的常见问题与排查4.1 双击 exe 无反应进程一闪就退现象双击sqldeveloper.exe后鼠标转两圈任务管理器里 Java 进程出现一瞬间就消失主界面永远出不来。原因这种情况十有八九是sqldeveloper.conf里SetJavaHome指向的 JDK 位数不对或者路径写错。另一个可能就是系统里装了不兼容的公共 JRESQL Developer 4.0.3.16.84 强制要求 JDK不是 JRE环境因为它启动时要调用javac相关的编译组件来处理 SQL 脚本里的 Java 存储过程。解决先检查sqldeveloper.conf把SetJavaHome改成一个确定无歧义的绝对路径例如SetJavaHome C:\Program Files\Java\jdk1.8.0_211然后在命令行手动执行一次D:\app\sqldeveloper\sqldeveloper\bin\sqldeveloper.exe这样能看到具体的错误输出。如果提示找不到jvm.dll说明路径里的 JDK 目录不完整如果提示UnsupportedClassVersionError说明你填了太高版本的 JDK这个版本的 SQL Developer 对 JDK 9 以上支持不好我建议固定用 JDK 8。4.2 连接时提示 ORA-12541: TNS 无监听程序现象在「基本」连接方式下填了正确的主机名和端口点测试却直接报ORA-12541: TNS:no listener。原因这个报错很迷惑因为它只说明客户端没有找到监听器不一定代表监听没起来。常见的有三种情况第一数据库服务器上监听服务没启动第二监听端口不是默认的 1521而你在 SQL Developer 里填了默认端口第三数据库跑在容器里端口做了映射但你在外部填的是容器内部端口。解决先在数据库服务器上确认监听状态用系统自带的命令lsnrctl status输出的监听端点列表里如果能看到(DESCRIPTION(ADDRESS(PROTOCOLTCP)(HOST*)(PORT1521)))则监听正常。此时回到客户端检查服务器防火墙或者云安全组是否放行了 1521 端口。排查顺序建议是先 ping 通主机 IP再 telnet 一下端口telnet 192.168.x.x 1521如果 telnet 提示无法连接说明端口根本不通SQL Developer 里填再多的参数都是白搭。这里不推荐用tnsping替代 telnet因为tnsping在某些环境里走 UDP 请求端口结果会误导判断。4.3 查询结果显示中文乱码现象SQL 工作表里查询出的中文数据显示成???或者一堆方框但同一张表里的数字和英文正常。原因这是客户端字符集和数据库服务端字符集不匹配导致的。SQL Developer 4.0.3.16.84 读取连接时默认采用 JVM 的file.encoding参数而这个参数在某些 Windows 中文环境下被本地系统语言干扰导致发送给 Oracle 的查询请求编码与服务端不一致。解决在 SQL Developer 的启动配置文件里加一行强制指定文件编码AddVMOption -Dfile.encodingUTF-8加完重启。如果重启后乱码依旧还要检查连接的 NLS 参数。在 SQL 工作表里执行ALTER SESSION SET NLS_NCHAR_CONV_EXCEPTION FALSE;不过这只能解决部分会话问题。最本质的做法是确认数据库端字符集执行查询SELECT VALUE FROM NLS_DATABASE_PARAMETERS WHERE PARAMETER NLS_CHARACTERSET;如果数据库端是ZHS16GBK客户端强行 UTF-8 也会出现显示问题。这种情况下我通常会把sqldeveloper.conf的编码参数删掉让 JVM 跟随系统默认编码反而能正确显示。4.4 导出 CSV 时数字变成科学计数法现象导出查询结果为 CSV 文件用 Excel 打开后长数字列显示成1.23457E15精度明显丢失。原因SQL Developer 4.0.3.16.84 默认导出行为里超过一定长度的 NUMBER 类型字段会被转成科学计数法这是工具内部把数据先转成字符串时使用了默认格式导致。它不影响数据库里的存储值但影响你导出去给业务方用。解决在导出向导的「格式选项」里把「数字格式」改成0或者指定的格式掩码。具体路径是查询结果区域右键 → 导出 → CSV → 下一步 → 找到「格式」设置把数字格式从默认的TM9文本最小表示改成99999999999999999999确保长度足够容纳所有整数位。关于这一点我自己的习惯是导出后用文本编辑器扫一遍关键列确认没有出现E字符再发给业务侧省得对方打开 CSV 后到处找人问「为什么订单号变成科学计数法了」。4.5 左侧对象树卡在「正在加载」现象连接成功后左侧树的表节点一直显示「正在加载」或者加载到某个表时卡住不动其他节点正常。原因SQL Developer 有一个「获取对象名」的机制它会向数据库查询ALL_OBJECTS相关的元数据。如果当前用户拥有的表数量特别大几千张以上或者对象的统计信息太久没收集树节点的展开请求就会超时表现为永远转圈。解决在「工具 → 首选项 → 数据库 → 对象查看器」里把「自动刷新」关掉同时把「获取对象名」的延时阈值调低。这些操作不需要重启连接但需要重新展开一次对应节点才生效。如果关闭自动刷新后仍然卡考虑给当前用户收集一下统计信息BEGIN DBMS_STATS.GATHER_SCHEMA_STATS(USER); END; /这条命令在生产库上执行耗时很长建议在维护窗口跑。如果只是为了平时开发查询方便我一般会直接告诉用户左侧树卡顿不代表连接有问题用 SQL 工作表直接写 SQL 查询就行连接本来就是通的。5. 验证连接后值得做的三件事快捷键、日志与导出规范化连接稳定之后多数人就把 SQL Developer 当成「能跑查询的窗口」用但 4.0.3.16.84 里还有三件事我认为值得做按投入产出比排序。第一件事是记住几个高频快捷键隔壁同事看着你操作以为你开了什么外挂。最常用的是CtrlEnter执行当前语句和F5执行整个脚本这两个的区别很多人用半年都没搞明白。CtrlEnter只执行光标所在的那一条 SQL适合调试单条语句F5会把整个工作表按顺序跑一遍适合初始化脚本。另一个值得记的是Ctrl7打开执行计划、CtrlF11解释计划看 SQL 性能时是刚需。写代码时想看表结构选中表名按ShiftF4对象详情直接弹出来不用在树里到处找。快捷键功能适用场景CtrlEnter执行当前语句单条 SQL 调试F5执行整个脚本跑初始化脚本Ctrl7执行计划分析慢 SQLShiftF4查看对象详情查看表结构、索引第二件事是开启日志记录。老版本 SQL Developer 的黑匣子默认不打开排查问题时只能靠猜。在sqldeveloper.conf里加一行AddVMOption -Dsqldev.debugtrue重启后在%APPDATA%\sqldeveloper\4.0.3.16.84下会生成更详细的日志文件。这个开关平时不用开遇到连接中途掉线、导入导出闪退这类问题再开定位速度快很多。我印象比较深的一次是排查「导入 Excel 时提示内存溢出」看日志才发现是 JVM 堆太小压根不是 SQL Developer 自身的问题。第三件事是固定导出格式。导出 CSV 时不要每次都用默认设置在「工具 → 首选项 → 数据库 → 导出」里把「行分隔符」设置成CRLFWindows 下 Excel 打开 CSV 乱行的主要原因编码选UTF-8。设置好后导出向导每次都会带出这套默认值不用每次重新选。这里多说一句如果你导出后要发给用 WPS 的同事分隔符选,是最稳妥的别选分号分号在一些区域设置下会被识别成公式分隔。从那次数字变科学计数法被业务方找上门之后我每次导数据给外部都强制走一遍「右键 → 导出 → 检查格式选项 → 打开文件确认」四步流程。SQL Developer 这个老版本虽然看着不惊艳但把连接、查询、导出、排查这几件事理顺了它就是最省心的数据库日常工具。希望这篇拆解能帮你避开我当年踩过的那些坑少花一晚上在研究 JDK 位数上。本文还有配套的精品资源点击获取