简介Oracle SQL Developer 4.0.3.16.84-x64 是面向Oracle数据库开发人员与DBA的64位免费图形化管理工具可用于建立数据库连接、编写与调试SQL/PL-SQL、浏览编辑数据、设计数据模型、生成报表、迁移数据及分析性能适合初学者快速上手也便于有经验者完成日常运维与开发。压缩包共含2000个文件约312.28MB主要由jar程序库、xml配置与元数据、sql脚本、exe启动程序、dll动态库及图片、帮助文档等组成目录层次完整便于查看组件与配置。已有772人学习下载说明其在Oracle工具入门与实务操作中具有一定参考价值。读者可通过该版本体验连接配置、对象管理、SQL调优、AWR报告和版本控制集成等功能并借助内置的SQL编辑器、数据建模、迁移与性能分析模块理解工具结构为数据库开发、迁移和性能排查提供可直接使用的桌面环境也可作为学习Oracle体系与日常维护的实用工具。1. 为什么现在还有人装 sqldeveloper 4.0.3.16.84-x64一个 JDK 引发的闪退上周又有人拿着台新装的 Windows 10 来找我说 sqldeveloper-4.0.3.16.84-x64 解压完双击 exe窗口一闪就没了任务管理器里连进程都留不下。这套组合我一年要碰七八回内网项目只开放 11g 的连接权限通用客户端不让装兜兜转转还是回到 SQL Developer 这个连 Oracle 数据库的免费工具上。它本身不复杂真正容易出问题的是它对 JDK 的挑剔——4.0.3 的基线是 JDK 7你机器上装着 JDK 17 它一个字都不会说只是安静地闪退连日志都不给你留。下面按解压、配 JDK、连库、验收到排错走一遍适合还在维护 10g/11g 老库、想留一份能长期用下去的连接工具的人。2. 装前把版本确定JDK 7、64 位客户端与路径规划这一章不讲怎么点下一步只解决三件必须在解压之前定下来的事用哪个 JDK、拿哪种包、放哪个目录。这三件事里任意一件错了后面所有步骤都是白费力气而且报错信息会把你往完全错误的方向引。2.1 版本对照4.0.3 认哪个 JDK内置驱动是哪一版SQL Developer 4.0.3 是 2015 年前后的产物它的运行依赖和今天的开发机环境差了一代。我一般会先照下面这张表把环境对一遍对不上的地方要么换版本要么提前准备好替换方案别等到启动失败再来查。项目4.0.3.16.84 的基线走偏之后的表现运行 JDKJDK 71.7.0_51 以上JDK 8 多数场景可用双击闪退、弹「Unable to create Java Virtual Machine」JDK 位数64 位程序必须配 64 位 JDK启动器直接退出或报 unsupported major.minor内置 JDBCojdbc 6 / 7 的 thin 驱动连 12c 以上新类型、长标识符时字段报错Oracle 客户端仅用 OCI 厚驱动时才需要必须 64 位找不到 oci.dll、Incompatible version用户配置目录%APPDATA%\SQL Developer\system4.0.3.16.84设置不生效、重启后偏好被重置安装路径无空格、无中文、当前用户可写启动器解析参数失败、配置写不进去JDK 8 到底能不能跑是问得最多的一句。我的经验是4.0.3 在 JDK 8 上启动、连库、写 SQL 都没问题但会有个别告警比如某些向导里的字体渲染异常、-XX:MaxPermSize提示被忽略。真正跑不起来的是 JDK 9 及以上模块化之后启动器根本找不到 JRE 的目录结构表现就是静默退出。所以本机如果同时装着多套 JDK不要改系统JAVA_HOME4.0.3 只认配置文件里写死的那个路径。至于驱动sqldeveloper\jdbc\lib下通常躺着ojdbc6.jar一类的文件。连 11g 完全够用连 12c、18c、19c 时如果遇到ORA-00904一类的奇怪报错常见做法是把更高版本的 ojdbc8 丢进这个目录并在首选项里指定而不是急着换客户端——这条后面第 4 章会展开。2.2 带 JDK 和不带 JDK 的包差在哪同一个版本号官方发过两种形态的包一种解压出来根目录里有个jdk文件夹一种没有。名字上看不出来解压完一眼就能判断所以我的习惯是先解压再决定后面怎么配而不是照着某篇教程无脑改配置文件。# 解压后先看根目录有没有 jdk这决定了要不要手写 SetJavaHome Get-ChildItem D:\oracle\sqldeveloper | Select-Object Name, Mode # 顺带确认三样关键文件都在启动器、配置、驱动 Test-Path D:\oracle\sqldeveloper\sqldeveloper.exe Test-Path D:\oracle\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf Get-ChildItem D:\oracle\sqldeveloper\sqldeveloper\jdbc\lib\ojdbc*.jar第一段列出根目录如果看到jdk目录说明这份包自带运行时sqldeveloper.exe会自动优先用它此时不要再去 conf 里加SetJavaHome——加了反而可能指向一个不存在的路径把原本能启动的环境弄坏。如果只看到sqldeveloper目录和 exe就必须自己指定 JDK 根目录。第二段是给自己留个底启动器、配置文件、驱动目录三样缺一不可有些二次打包的资源会莫名其妙少掉jdbc\lib那种包装上去连驱动都加载不了。还有一种情况是机器上已经有 JDK但版本是 11 或 17。这时不要为了这个工具去卸现有的 JDK两套并存完全没问题只需要在sqldeveloper.conf里把路径写死到 1.7 或 1.8 的目录工具自己会去加载不影响系统里其他程序。2.3 路径与权限别放进 Program Files别带中文这一条看起来像废话但确实是我见过最多的启动失败原因之一。SQL Developer 运行时会把用户配置写到%APPDATA%同时会在安装目录里读写一些临时文件一旦装到C:\Program Files下普通用户对目录没有写权限表现就是启动到一半卡住、或者偏好设置改完重启就丢。我的固定做法是统一放在盘符根下的短路径比如D:\oracle\sqldeveloper。短路径还有两个好处一是SetJavaHome那一行不用担心空格转义的问题二是 JDK 路径里如果带空格某些老版本启动器解析参数会直接把路径截断报出来的错跟路径毫无关系查起来很浪费时间。中文路径同样要避开。有人喜欢把工具放在「桌面\数据库工具\」下面桌面本身就在中文用户名目录里这一层套下来用户配置目录也会跟着出现中文个别 JDBC 相关日志写入时会出现编码问题。判断方法很简单echo %APPDATA%如果输出里带中文就把工具整个挪到 D 盘不要让用户目录参与进来。最后是权限虽然不装在 Program Files但如果这台机器是多人共用建议解压后右键目录看一眼安全页确认当前账号有修改权限。实在不放心可以在首次启动后用管理员身份跑一次把配置目录先生成出来之后再用普通账号启动就不会再触发写权限问题。3. 安装与首次启动SetJavaHome 那一行必须写对解压就能用的工具所谓「安装」其实就是配一个配置文件。这一章按顺序走完三件事确认目录结构、改配置文件、完成首次启动。每一步我都会说明改的是哪一行、为什么改、改错会怎样照着抄完应该能直接看到启动画面。3.1 解压后的目录结构确认先把包解压到规划好的位置不要图省事直接在压缩包里双击运行那样运行时的工作目录不确定配置文件的相对路径会解析到临时目录里表现就是「明明改了配置重启之后还是老样子」。# 统一解压到 D:\oracle 下最终得到 D:\oracle\sqldeveloper New-Item -ItemType Directory -Path D:\oracle -Force | Out-Null Expand-Archive -Path .\sqldeveloper-4.0.3.16.84-x64.zip -DestinationPath D:\oracle -Force # 看一眼关键子目录记住这几个路径后面全靠它们排错 Get-ChildItem D:\oracle\sqldeveloper\sqldeveloper -Directory | Select-Object -ExpandProperty NameExpand-Archive在 PowerShell 5 之前对中文文件名支持一般如果解压报错或者发现文件缺失换 7-Zip 解压一次即可这不是工具的问题是解压器的问题。第二段列出的子目录里bin放配置文件和启动参数jdbc\lib放驱动modules放主体模块还有个..\..\jdk可能在上一层。记住bin的绝对路径下一步就靠它。解压完成后先别急着双击。先手动新建一个快捷方式放到桌面右键属性里把「起始位置」设成D:\oracle\sqldeveloper这样每次启动的工作目录是固定的配置文件永远读得到。3.2 sqldeveloper.conf 里要改的几行这份配置是纯文本用任意编辑器打开都能改但要用不带 BOM 的 UTF-8 或者直接用 ASCII编辑器自动加的 BOM 会让启动器第一行解析失败报错信息里会带个乱码字符看着像编码问题其实是 BOM。# 文件位置D:\oracle\sqldeveloper\sqldeveloper\bin\sqldeveloper.conf # 工具会按这个顺序找 JDKconf 里的 SetJavaHome 自带的 jdk 目录 系统 JAVA_HOME # 指向 JDK 根目录不是 bin也不是 jre 子目录 SetJavaHome D:\java\jdk1.8.0_202 # 堆内存默认值偏小对象浏览器展开大 schema 时会卡死 AddVMOption -Xmx1024M AddVMOption -XX:MaxPermSize256M # 内网机器 DNS 反查经常要等十几秒这一行能省掉启动时的空白期 AddVMOption -Djava.net.preferIPv4StacktrueSetJavaHome后面跟的是 JDK 的根目录判断标准是这个目录下同时有bin和jre两个子目录。指向bin会报找不到虚拟机指向jre目录虽然有时能起来但缺少编译器相关组件后面用某些导出功能会莫名其妙失败。这一行如果写错工具不会告诉你「路径不对」而是直接闪退所以出问题时第一个要回来看的就是这行。-Xmx1024M是堆上限。4.0.3 的默认值在 32 位时代定下来的如今随便一个库的表数量都能把它撑爆。1024M 对绝大多数人够用机器内存充裕的话给到 2048M 也行但不建议给太大因为它是启动时就申请的配合-XX:MaxPermSize一起调更稳。JDK 8 会提示MaxPermSize被忽略这属于正常现象不影响使用不想看到告警就把它删掉。preferIPv4Stack这行是纯经验项。很多内网机器的 DNS 配置不完整程序启动时会尝试解析本机主机名IPv6 解析超时后才回落期间界面是白屏的新同事经常以为是卡死了直接强杀。加上这行之后启动时间从二十几秒降到几秒属于一次配置长期受益。提示改完配置先别保存多个副本。sqldeveloper.conf.bak这类文件放在bin目录里本身不影响启动但下次再改配置时容易改错文件我吃过这个亏。3.3 首次启动与用户配置目录落地双击启动器第一次会看到选择配置目录的提示问你是要沿用已有配置还是新建一个。新机器直接选新建会生成%APPDATA%\SQL Developer\system4.0.3.16.84这个目录之后所有的连接定义、编辑器偏好、SQL 历史都在里面。这个目录值得单独记一下因为迁移机器时它就是全部家当。换电脑的时候不用一个个重建连接把整个system4.0.3.16.84拷到新机器的同名路径下启动后连接列表原样都在。注意版本号要对得上从 4.0.3 的目录拷到 4.1 的环境里工具会做一次配置升级大部分设置能保留但布局类的东西可能会重置。首次启动如果卡在启动画面超过一分钟先看任务管理器里进程的 CPU 占用。如果一直是 0多半是 JDK 路径的问题回到 3.2 检查SetJavaHome如果 CPU 是满的那是在解压模块或者建缓存等两三分钟属于正常第二次启动就快了。启动成功后先把首选项里的两项调掉一是Database NLS里的日期格式改成YYYY-MM-DD HH24:MI:SS否则查询结果里的时间列默认是DD-MON-RR这种格式看着别扭还容易误读二是Environment Fonts里的编辑器字体换成等宽的中文在默认字体下经常对不齐列。4. 连接配置连接串、TNS、字符集与厚驱动工具跑起来了接下来是真正要用它干的事——连上库。这一章的四个小节对应四种典型失败连不上、连错了、连上之后是乱码、想用高级特性结果加载不了客户端。每一种我都给出具体的填法和判断依据。4.1 新建连接SID 和 Service Name 别填反新建连接时最常见的困惑是「服务名」那一栏到底填什么。11g 之前很多库用的是 SID12c 之后基本都走服务名两者在监听器眼里是两个不同的东西填错报的错也不一样。连接方式什么时候用关键字段Basic主机名 端口 SID老库只知道 SID没有服务名SID 填实例名通常是库名大写Basic主机名 端口 服务名主流方式RAC 和 PDB 都走这个服务名可用lsnrctl status确认TNS机器上已经有tnsnames.ora想复用别名网络别名需先配好 TNS 目录高级自定义 JDBC URL需要额外参数比如超时、字符集完整 URL字段格式最灵活报错能直接定位ORA-12505是监听器不认识你给的 SIDORA-12514是监听器不认识你给的服务名。这两个错看着像网络问题实际上九成是字段填反了。确认服务名的办法是在数据库服务器上执行lsnrctl status输出里Service orcl has 1 instance(s)这一段就是答案注意它可能和实例名不同。如果是 RAC 或者有多个节点主机名那栏别填 VIP 的地址填 SCAN 名或者直接在高级里写完整 URL把多个地址列进去。填单个节点也能连但节点故障切换时会断连重连一次才能恢复。4.2 tnsnames.ora 目录怎么指手里已经有tnsnames.ora的话最省事的做法是让工具直接读这个文件别名、地址、服务名全在里面不用在界面上一个个敲。# tnsnames.ora 片段放在 D:\oracle\network\admin\ 下 ORCL11G (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST 10.0.0.21)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME orcl) # 这里是服务名不是 SID ) )写完之后在工具的Tools Preferences Database Advanced里把Tnsnames Directory指向D:\oracle\network\admin。这一步不做的话新建连接时选 TNS 类型会是一张空列表很容易误以为文件写错了。两个注意点HOST不要写localhost除非数据库真在本机写主机名的话要确认客户端能解析SERVICE_NAME和SID是两个参数老库如果没有服务名把这一行换成(SID orcl)同样能用。改完tnsnames.ora不需要重启工具但需要重新打开一次新建连接窗口才会刷新列表。指向目录之后界面上新建连接选「TNS」类型网络别名下拉框里就会出现ORCL11G。这个方式的好处是连接信息集中在一处维护团队里几个人共用一份文件改地址不用挨个通知。4.3 字符集乱码要分清是哪一层的问题中文乱码是这类老工具最经典的坑但乱码的原因分三层不分清楚就会一直在错误的地方改。第一层是客户端环境的NLS_LANG第二层是会话级的NLS_LANGUAGE和NLS_TERRITORY第三层才是编辑器字体。先看数据库本身的字符集这一层决定了数据存进去是什么编码-- 数据库字符集AL32UTF8 是 UTF-8ZHS16GBK 是 GBK SELECT parameter, value FROM nls_database_parameters WHERE parameter IN (NLS_CHARACTERSET, NLS_NCHAR_CHARACTERSET); -- 当前会话的语言和日期格式跟首选项里的设置对照 SELECT parameter, value FROM nls_session_parameters WHERE parameter LIKE NLS_%;如果数据库是ZHS16GBK客户端系统环境里的NLS_LANG一般要设成SIMPLIFIED CHINESE_CHINA.ZHS16GBK数据库是AL32UTF8就设成AMERICAN_AMERICA.AL32UTF8。这个变量是 Windows 系统环境变量设完要重新开一个终端或者重启工具才生效很多人设完立刻去看结果发现没变化就以为方法不对其实只是没重启。会话级的那两个参数可以在首选项里改位置在Database NLS把Language设成SIMPLIFIED CHINESE、Territory设成CHINA。这一层影响的是日期格式和排序规则跟数据显示的编码关系不大但如果日期显示成01-JAN-24这种就是这里没配。第三层是字体。前两层都对中文还是显示成方块那就是编辑器字体不支持中文换成Consolas或者系统自带的等宽中文字体即可。判断方法很直接查询结果里中文正常、只有编辑器里的注释是方块那就纯字体问题跟编码一点关系没有。4.4 厚驱动与 Instant Client位数必须对齐默认走的是 thin 驱动纯 Java 实现不需要任何 Oracle 客户端绝大多数场景够用。但有些功能必须用 OCI 厚驱动比如读取某些 LOB 类型、用到特定的加密算法、或者需要和客户端的sqlnet.ora配置保持一致。# 确认 Instant Client 是 64 位目录下必须有 64 位的 oci.dll Get-ChildItem D:\oracle\instantclient_19_3\oci.dll | Select-Object Name, Length # 把客户端目录加进 PATH工具启动时才能找到依赖 [Environment]::SetEnvironmentVariable( PATH, $env:PATH;D:\oracle\instantclient_19_3, Machine )64 位的 SQL Developer 只能加载 64 位的oci.dll这一点没有任何绕过办法。常见的报错是Incompatible version或者笼统的「无法加载 OCI 库」原因基本都是机器上装了个 32 位客户端或者 PATH 里排在前面的那个客户端是 32 位的。判断方法是在 PowerShell 里看oci.dll的文件大小32 位的一般在 400KB 上下64 位的接近 800KB差距很明显。配置完成之后在连接的属性里勾选「Use OCI/Thick driver」然后重启工具。这一项是懒加载的勾完不重启不会生效很多人勾完直接点测试连接看到还是 thin 的行为就以为没生效。重启后连上去执行SELECT * FROM v$session一类的视图如果能查到更多字段说明厚驱动确实加载成功了。另外一条经验既然默认 thin 就够用就不要为了「看起来更专业」去开厚驱动。多一个客户端就多一层版本兼容问题尤其是同一台机器上还有别的 Oracle 相关工具时PATH 冲突排查起来非常费时间。5. 避坑与排查五条现场记录下面五条都是我在别人机器上实际处理过的问题按现象、原因、解决三段写。如果你正在其中某一条上卡着先照着对应段落的判断方法确认一下别急着大面积重装。5.1 启动阶段的三条现象一双击 exe 之后窗口闪一下就消失任务管理器里看不到进程。原因基本锁定在 JDK。要么SetJavaHome指向的不是 JDK 根目录要么指向的是一个不存在的路径要么本机根本没有 4.0.3 能识别的 JDK 版本。工具在启动器这一层拿不到虚拟机就直接退出不会写日志所以看起来毫无线索。解决方法是打开命令行切到sqldeveloper\bin目录下手动执行启动脚本这样报错会打到控制台上。看到Unable to create Java Virtual Machine就回去改SetJavaHome看到路径相关的乱码字符检查配置文件是不是被编辑器存成了带 BOM 的格式。改完保存重新双击。现象二启动画面停在白屏进度条一动不动强杀之后重开还是一样。原因是启动阶段在做主机名解析内网 DNS 不完整的情况下这一步会超时超时时间取决于系统配置有时候能拖到一分钟以上。另外堆内存给小了也会在加载模块时卡住表现和 DNS 问题很像。解决办法分两步先在sqldeveloper.conf里加AddVMOption -Djava.net.preferIPv4Stacktrue再把-Xmx提到 1024M。两步都做完重启正常情况下启动时间会降到十秒以内。如果还是卡在命令行启动看输出卡在哪一行一目了然。现象三用着用着突然整个窗口关掉没有任何提示。这是内存溢出被系统直接终止的典型表现尤其是展开一个几百张表的 schema、或者导出大结果集的时候。默认堆上限撑不住这种操作进程被操作系统回收界面上什么都不会留下。解决办法是把-Xmx调大同时养成习惯不要在对象浏览器里一次性展开所有节点导出数据时用「导出向导」分批次而不是直接全选。真要处理大数据量用命令行工具或者分页查询更稳图形界面不是干这个的。5.2 连接阶段的两条现象四连接测试报ORA-12505或ORA-12514但用别的工具同样的地址能连上。ORA-12505说明监听器不认识你填的 SIDORA-12514说明不认识你填的服务名。同一个地址在别的工具里能连往往是因为那个工具填的是服务名而这里填的是 SID或者反过来。解决方法是登录数据库服务器执行lsnrctl status把输出里Service和Instance两段看清楚。如果库里同时存在实例名和服务名优先用服务名如果是老库只有 SID就在新建连接时把类型切到 SID 那一档别混着填。现象五连上了查询结果里中文全是问号或者方块。先分清是哪一层的问题如果查询结果里中文异常但数字英文正常是编码问题如果只有编辑器里的中文是方块是字体问题。编码问题再看数据库字符集ZHS16GBK和AL32UTF8对应的NLS_LANG设置完全不同设错方向会一直乱码。解决方法是按 4.3 的三层顺序排查先确认数据库字符集再设系统环境变量NLS_LANG重启工具后新建一个连接测试。不要在原连接上反复改会话参数是连接建立时读取的改完必须重连才生效。6. 装完怎么验证三层确认加一张自检表工具装完、连接配好最后一步是确认它真的能用而不是「能启动、能连上」就算完事。我一般按三层验进程层确认 JDK 加载对了连接层确认网络和认证通语句层确认权限和字符集都对。三层都过这套环境才算落地。第一层在命令行做不用打开界面# 1) JDK 版本和位数必须和 sqldeveloper.conf 里写的一致 D:\java\jdk1.8.0_202\bin\java.exe -version # 2) 启动器进程能起来并稳定存活十秒说明虚拟机加载成功 Start-Process D:\oracle\sqldeveloper\sqldeveloper.exe Start-Sleep -Seconds 10 Get-Process sqldeveloper -ErrorAction SilentlyContinue | Select-Object Id, CPU, WorkingSet-version的输出里如果带64-Bit说明位数对得上WorkingSet稳定在几百 MB 说明内存参数生效了如果只有几十 MB 且 CPU 一直为 0那还是启动阶段的问题回到第 5 章第一条。第二层在工具里新建一个连接点「测试」成功之后立刻执行下面这段 SQL。这一段的作用是把「能连」升级成「能用」-- 实例信息确认连的是目标库不是同名的测试库 SELECT instance_name, host_name, version, status FROM v$instance; -- 当前用户能看到多少表验证权限是否完整 SELECT COUNT(*) AS table_cnt FROM user_tables; -- 字符集再确认一次和客户端设置对照 SELECT parameter, value FROM nls_database_parameters WHERE parameter NLS_CHARACTERSET;v$instance里的host_name是最直接的证据一眼就能看出连的是哪台机器。user_tables的计数如果为 0 但库里明明有表那是权限没给到不是工具的问题。字符集这一条是给后面写数据留的底如果这里显示ZHS16GBK而你的NLS_LANG设的是 UTF-8早晚要在中文数据上出问题。第三层是自检表装完一台机器我会逐项打勾任何一项不对都先解决再交付检查项期望结果不通过时先看哪里启动耗时十秒内出界面preferIPv4Stack和 DNS 配置JDK 来源与 conf 中一致SetJavaHome那一行连接测试成功且耗时低于两秒SID / 服务名是否填反中文显示查询结果和编辑器都正常三层字符集逐层排导出功能能导出百行 CSV 不闪退-Xmx是否够用配置持久化重启后偏好还在安装目录写权限那张表里最容易被忽略的是最后一项。有人装完之后每次重启都要重新设一遍日期格式查了半天以为是工具的 bug实际是装在了只读目录里配置根本写不进去。所以我现在装完第一件事就是改一个偏好、关掉、重开、看它还在不在这个动作三十秒能省掉后面半小时的排查。从那以后我每次给别人的机器配这套环境都强制走一遍「命令行验 JDK → 界面验连接 → SQL 验权限和字符集 → 重启验配置持久化」这四步不管对方多急都走完。工具本身不复杂复杂的是那些不报错就直接失败的地方而这四步恰好能把它们全都暴露出来。希望帮到你。本文还有配套的精品资源点击获取