简介：面向Oracle APEX初学者与中级开发者的《Oracle APEX深入浅出》文档，聚焦从环境搭建到企业级应用落地的完整开发路径，适合需要系统掌握APEX页面设计、控件使用、报表与图表实现及调试部署的读者。压缩包仅含1个doc文件，约8.11MB，以章节化开发指南形式组织，便于按目录检索与通读。内容覆盖APEX系统探究、账户与权限管理、开发概要、页面布局美化、常用控件、Report增删改、文件上传下载、CSS与JS应用、图表报表、插件、部署以及EBS集成等主题，并涉及调试技巧与常用API。已有1593人学习，可作为开发过程中查阅控件配置、报表数据源与页面交互实现的参考，也能帮助读者理解APEX与Oracle数据库、EBS环境配合时的关键环节，逐步搭建规范的企业应用开发思路。

1. 装完 4.2.5 却登不进 apex_admin：这套环境难在哪

有一类翻车特别典型：数据库是 Oracle 11g，出厂自带 APEX 3.0，你把 4.2.5 的安装包解开、apexins.sql一路回车跑完，http://server:8888/apex/apex_admin页面也出来了，结果 ADMIN 账号怎么输都提示认证失败。密码改了三次、数据库重启两回，问题依旧。这不是密码的锅，而是老版本残留用户在认证链路上截了胡——APEX 的登录校验并没有你想象中那么"干净"。Oracle APEX 深入开发这件事，门槛从来不在写页面，而在环境这一步：数据库版本决定网关选型，网关选型决定端口和参数，账户层级又决定后面开发者能不能登进去。这篇记录面向的是要在 11g 上把 APEX 4.2.5 从零装起来、并且能自己排查故障的人，新手照着能走通，熟手能看到版本差异和参数取舍。

2. 版本与依赖先定死：Oracle 11g 配 APEX 4.2.5 的环境清单

装 APEX 之前最该做的一件事，是把版本组合先钉死。APEX 不是独立进程，它整套东西都驻留在数据库里——页面定义是表里的数据，页面渲染是一堆 PL/SQL 对象，浏览器发来的 URL 被解析成 PL/SQL 调用，结果用sys.htp.p拼成 HTML 吐回去。所以数据库版本直接决定了你走哪条 HTTP 通路，这条通路选错，后面所有步骤都是白费。

2.1 数据库版本决定 HTTP 服务器怎么选

11g R1、R2 自带 PL/SQL 网关（EPG），配置简单，不需要额外装 Web 服务器，装完就能对外提供 HTTP 服务，适合单机验证和内部系统。10g 就没这个便利，必须用 mod_plsql 插件挂到专业 HTTP 服务器上，或者单独部署 APEX Listener 来对接。这个差别不是"方便不方便"的问题，而是安装脚本、端口、监听注册全都不一样。

我一般在这三种组合里选：

本次环境走的是第一行：Linux 4 系发行版 + Oracle 11g + 虚拟机软件，安装包用apex_4.2.5.zip。选它不是因为先进，而是因为链路最短——数据库起来，网关就在里面，少一个组件就少一个黑匣子。把虚拟机状态置为挂起而不是关机，下次打开省掉一堆参数重配，这是我踩过几次"重启后端口没起来"之后养成的习惯。

2.2 表空间、字符集与浏览器的最低门槛

APEX 安装至少要吃两个表空间：一个放 APEX 自身的元数据和 PL/SQL 对象，一个放用户上传的文件（BLOB）。临时表空间用系统默认的就行。这次只建了一个apex01，两个用途都指过去，图省事；生产上我一般会拆成apex01和apex_files两个，文件表空间单独做备份策略。

-- 以 sysdba 身份执行，数据文件路径按现场实际目录改 CREATE TABLESPACE apex01 DATAFILE '/d01/oracle/ORCL/db/apps_st/data/apex01.dbf' SIZE 100M AUTOEXTEND ON NEXT 100M MAXSIZE 1000M;

SIZE 100M是起步值，AUTOEXTEND ON NEXT 100M保证写满后每次扩 100M，MAXSIZE 1000M是封顶，防止某个跑飞的导入把磁盘吃干净。不确定数据量的时候别把 MAXSIZE 设成 UNLIMITED，这是血泪经验。

浏览器侧的门槛比想象中低，但也不能忽略。APEX 要求浏览器支持 JavaScript、HTML 4.0 和 CSS 1.0：

现在任何一台机器都超过这个线，真正容易出问题的是内网里的老机器和 IE 兼容模式——页面能开但控件渲染错位，先怀疑浏览器，别急着改代码。字符集这块，数据库建库时定的字符集决定了中文能不能正常显示，后期装中文语言包只是把界面翻译过来，不会改变存储编码。

2.3 安装包、解压目录与操作账号

安装包上传到$ORACLE_HOME下再解压，是为了让sqlplus执行脚本时相对路径好找；但我更推荐单独建一个/apex目录解压，原因是$ORACLE_HOME/apex里本来就躺着 11g 自带的 3.0 安装脚本，两个版本混在一起，哪次手滑执行错了脚本，后果比想象中严重。目录规划如下：

# 独立目录，别和 $ORACLE_HOME/apex 里的 3.0 脚本混在一起 mkdir -p /apex cd /apex unzip /tmp/apex_4.2.5.zip -d /apex ls /apex | head

解压后应该能看到apexins.sql、apxconf.sql、apxremov.sql、builder/这些。操作账号用系统 DB 用户（有 DBA 权限的那个），整个安装过程都在sqlplus / as sysdba里完成，不需要另建安装用户。安装前先确认两件事：SELECT version_no FROM apex_release;看当前是什么版本，SELECT tablespace_name FROM dba_tablespaces;看apex01有没有建成功。这两条查完再往下走，能省掉后面一半的返工。

3. 从卸载 3.0 到跑通 8888：APEX 4.2.5 安装全流程

整个安装可以拆成五段：卸旧版、建表空间解压、跑安装脚本、配网关、收尾。顺序不能乱，尤其是第一段——11g 自带的 3.0 不卸干净，4.2.5 装上去之后两个版本的元数据表会打架，表现出来就是第 1 章说的那个"密码怎么都不对"。

3.1 清掉 11g 自带的 APEX 3.0

先确认版本再动手。在$ORACLE_HOME/apex目录下执行卸载脚本，脚本会二次确认，输入YES才真正执行：

-- 先看当前版本，11g 出厂通常是 3.0 SELECT version_no FROM apex_release; -- 卸载 3.0，脚本在 $ORACLE_HOME/apex 下 @apxremov.sql

apxremov.sql会把 APEX 相关对象连同APEX_030200这个 schema 用户一起 drop 掉。不同小版本的脚本名有差异，11.2 后期的包里多了apxremov_con.sql（只删对象、保留用户）和apxremov1.sql/apxremov2.sql这种分步版本，执行前先ls看一眼目录里到底有哪个，别照抄别人的命令。卸载完再跑一次SELECT version_no FROM apex_release;，应该报错说表不存在，这才算干净。

卸载完顺手把安装目录也清一下：

cd /apex rm -rf *.* # 确认当前在 /apex 下再执行，别在 $ORACLE_HOME 里跑这条

这一步被不少人忽略，结果 4.2.5 的脚本和 3.0 的脚本混在同一个目录，@apexins.sql执行时加载到了旧文件，装完版本号对不上。清目录之前先pwd确认位置，这是后悔药。

3.2 建 apex01 表空间并解压安装包

表空间 DDL 见 2.2 节，建完用dba_tablespaces确认。然后把下载的apex_4.2.5.zip上传并解压到/apex。解压完建议先看一眼关键脚本在不在：

# 确认核心脚本齐全，缺文件的话后面每一步都会报错 ls -l /apex/apexins.sql /apex/apxconf.sql /apex/apxremov.sql

三个脚本分别对应安装、配网关、卸载。如果apexins.sql不在，说明压缩包没解压完整或者版本包结构不同（有些版本把脚本放在apex/子目录里），这时候别硬跑，先把目录结构搞清楚。安装脚本执行时会往数据库里灌几万个对象，中途中断的代价是重来一遍，所以表空间、目录、脚本三件事确认完再开始。

3.3 执行 apexins 与解锁 APEX_PUBLIC_USER

安装主脚本是apexins.sql，四个参数依次是：APEX 对象表空间、文件表空间、临时表空间、图片虚拟路径。4.2 版本图片路径统一用/i/：

-- 依次是：APEX 对象表空间、上传文件表空间、临时表空间、images 虚拟路径 @apexins.sql APEX01 APEX01 TEMP /i/

执行时间看机器性能，十几分钟到半小时都正常，中间不要 Ctrl+C。跑完之后要处理几个系统用户：

-- ADMIN 是 APEX 的超级管理员，密码必须够复杂 ALTER USER APEX_040200 IDENTIFIED BY "Apex#2025_Strong" ACCOUNT UNLOCK; -- 公共用户与匿名用户，不解锁后面访问会直接被拒 ALTER USER APEX_PUBLIC_USER ACCOUNT UNLOCK; ALTER USER ANONYMOUS ACCOUNT UNLOCK;

APEX_040200这个用户名里的数字就是版本号，4.2 对应 040200，装 5.x 会变成APEX_050000，所以看到别人文档里写APEX_040100别照抄。密码复杂度是硬要求，必须包含大写、小写、数字和特殊符号，否则直接抛ORA-28003。这一步最容易犯的错是把APEX_040200当成临时用户随手 drop——它一旦没了，整套 APEX 对象全部失效，只能重装，没有任何补救手段。

3.4 配置嵌入式 PL/SQL 网关与 8888 端口

网关配置脚本是apxconf.sql，它会以交互方式问你三件事：数据库主机名、HTTP 端口、ADMIN 账户密码。端口这次填 8888（默认是 8080，内网里 8080 常被别的服务占着，换个端口更省事）：

-- 交互式配置 EPG，依次输入主机名、端口 8888、ADMIN 密码 @apxconf.sql

脚本跑完还要确认共享服务器开着，EPG 依赖它把 HTTP 请求分发到数据库进程：

-- shared_servers 为 0 的时候 EPG 起不来，页面就是 404 SHOW PARAMETER shared_servers; -- 静态参数，改完要重启实例 ALTER SYSTEM SET shared_servers = 1 SCOPE=SPFILE;

配置完成后访问http://server:8888/apex和http://server:8888/apex/apex_admin。如果出现 HTTP 404，先别怀疑安装失败——绝大多数情况是网关没起来。排查顺序我一般是：curl -I http://127.0.0.1:8888/apex/apex_admin看端口通不通，SHOW PARAMETER shared_servers看是不是 0，最后看监听器状态里有没有 HTTP 服务注册。三处都正常还 404，再回头检查apxconf.sql是不是中途被打断了。

3.5 中文语言包、ACL 与参数收尾

界面要中文就装语言包。4.2 的语言包脚本在解压目录的builder/<语言>/下：

-- 中文语言包，路径随解压目录，执行前先 ls 确认文件存在 @builder/zh-cn/load_zh-cn.sql

语言包装完不会立刻生效，要在 APEX 管理界面里把实例的默认语言改过来，或者每个应用单独设置。这点经常被误解成"装了没用"。

APEX 里有些功能（邮件、Web 服务调用、外部 HTTP 请求）需要出站网络权限。11g 用 ACL 控制，给APEX_040200授一个任意主机的外连权限：

BEGIN -- 创建一个 ACL 文件（虚拟的，落在 XML DB 里），允许 APEX_040200 外连 DBMS_NETWORK_ACL_ADMIN.CREATE_ACL( acl => 'apex_net.xml', description => 'APEX outbound access', principal => 'APEX_040200', is_grant => TRUE, privilege => 'connect'); -- 绑定到所有主机；生产上建议改成具体域名，别图省事写 '*' DBMS_NETWORK_ACL_ADMIN.ASSIGN_ACL( acl => 'apex_net.xml', host => '*'); END; /

host => '*'是图省事的写法，正式环境按需要连的域名逐个授权，否则等于给数据库开了个任意出站的口子。最后调两个参数收尾：

-- APEX 的后台任务（邮件队列、工作表、应用构建）依赖 job queue ALTER SYSTEM SET job_queue_processes = 20 SCOPE=BOTH; -- 复杂页面会开不少游标，默认值偏小 ALTER SYSTEM SET open_cursors = 1000 SCOPE=BOTH;

job_queue_processes设 0 的时候 APEX 表面能跑，但邮件发不出去、构建任务永远排队，现象很玄学，查半天查不到原因。这两个参数改完不用重启，但shared_servers那个要重启才生效。

4. 账户三层结构落地：ADMIN、Workspace 与 Developer 怎么建

APEX 的权限模型是三层：ADMIN 是实例级超管，Workspace 是工作空间（相当于一个工程），每个 Workspace 下面还有工作空间管理员、开发者、应用最终用户三种角色。很多人装完直接拿 ADMIN 去开发，这在单机验证时没问题，一旦要给业务方用，就必须把层级切开。

4.1 三层账户的权限边界

一个 Workspace 绑定一个数据库 Schema，这一点要理解透：Workspace 是逻辑工程，Schema 是物理对象归属。绑了哪个 Schema，这个空间里建的表、视图、存储过程就落在哪个 Schema 下，APEX 用APEX_PUBLIC_USER做代理连接过去。所以给业务系统建空间时，要绑到业务已有的 Schema 上，别随便新建一个空 Schema，否则开发到一半发现查不到业务表。

4.2 建 Workspace 并绑定业务 Schema

最直接的路子是用 ADMIN 登录apex_admin，在界面上建 Workspace：填空间名、绑 Schema、设空间管理员账号密码。如果是批量建或者要写进部署脚本，用 API 更省事：

-- 用 SQL 建 Workspace，省去界面点点点，适合写进部署脚本 BEGIN APEX_INSTANCE_ADMIN.ADD_WORKSPACE( p_workspace => 'ERP_WS', -- 空间名，全实例唯一 p_primary_schema => 'BIZ_SCHEMA' -- 绑定的业务 Schema，必须已存在 ); COMMIT; END; /

p_workspace是空间标识，后面开发者登录时要输这个名字；p_primary_schema必须提前在数据库里存在，否则报错。API 建完不会自动生成空间管理员密码，得再用APEX_INSTANCE_ADMIN.ADD_USER补一个，或者直接进界面重置。我一般习惯界面建第一个空间把流程走通，确认没问题后再用 API 批量建剩下的，这样出问题能立刻定位是 API 参数问题还是环境问题。

空间建好后，用空间管理员登录，给这个空间加两类用户：开发者（Developer）和应用最终用户（App End User）。开发者能进 App Builder 建页面，最终用户只能登录跑应用。这两个角色别混，混了之后最终用户能看到全部表结构和 SQL 语句，安全上说不过去。

4.3 Application 的 7 种认证方式怎么挑

建 Application 时会让选认证方式，APEX 自带 7 种。实际项目里常用的就两种：

• Application Express Accounts：用 APEX 自己维护的用户名密码登录，适合内部工具、开发验证、用户量小的场景。用户在 Workspace 里建，不用对接外部系统。
• HTTP Header Variable：从 HTTP 请求头里取用户名，适合已经有统一认证入口的系统。用户从 ERP 套件或门户点进来时，请求头里带着身份信息，APEX 直接信任，不用二次登录。

选 HTTP Header Variable 有个前提：请求头必须是可信来源写进去的，否则任何人伪造一个头就能冒充登录。所以这种模式一般只在前置有统一入口、并且网络层做了限制的环境里用。开发阶段我建议先用 Application Express Accounts 把应用跑通，等功能定下来再切认证方式——认证方式在应用建好后是可以改的，不用重建。

5. 登录失败与 404：APEX 4.2.5 安装排错清单

装 APEX 遇到的问题高度集中，翻来覆去就那几类。下面五条是实际踩过的，按现象、原因、解决写，遇到类似的直接对号入座。

5.1 认证一直不过与误删 APEX_040200

坑一：ADMIN 密码改了无数次，登录还是认证失败

现象：apex_admin页面能打开，输入 ADMIN 和刚改的密码，提示认证失败。重启数据库、重设密码都无效。

原因：数据库里还残留着 3.0 版本的用户。11g 自带的 APEX 3.0 卸载不彻底时，APEX_030200之类的用户还在，登录校验走的仍是老版本的链路，你改的是 4.2 的 ADMIN 密码，校验的却是另一套东西。

解决：先把所有 APEX 前缀的用户列出来，看清楚有几个版本：

-- 正常情况下只应该看到 APEX_040200、APEX_PUBLIC_USER 这一套 SELECT username, account_status FROM dba_users WHERE username LIKE 'APEX%';

发现APEX_030200这类残留，直接 drop 掉，然后重新登一次：

-- 确认是旧版本残留再执行，drop 之后不可恢复 DROP USER APEX_030200 CASCADE;

坑二：手滑把 APEX_040200 删了

现象：执行DROP USER ... CASCADE时没看清对象，把APEX_040200一起删了，之后所有 APEX 页面全部 500，管理界面彻底打不开。

原因：APEX_040200持有整套 APEX 元数据和 PL/SQL 对象，删它等于把 APEX 从数据库里挖掉。

解决：没有后悔药，只能重装。回到 3.2 节，确认表空间还在、安装包还在，重新跑一遍@apexins.sql。重装前先确认残留对象清干净了，否则新装也会报错。这件事之后我养成了一个习惯：执行DROP USER之前先把用户名单独复制出来核对一遍，尤其是LIKE 'APEX%'查出来的结果，永远不要直接拿去批量 drop。

5.2 端口、网关与表空间类故障

坑三：访问 8888 端口直接 404

现象：安装脚本全部跑完没报错，浏览器打开http://server:8888/apex/apex_admin返回 404。

原因：EPG 没起来。最常见的是shared_servers参数为 0，其次是apxconf.sql中途被打断导致 DAD 没建全，再其次是监听器没注册 HTTP 服务。

解决：按顺序查三处：

# 第一处：端口本身通不通 curl -I http://127.0.0.1:8888/apex/apex_admin

-- 第二处：共享服务器是否开启，为 0 就改成 1 并重启实例 SHOW PARAMETER shared_servers; ALTER SYSTEM SET shared_servers = 1 SCOPE=SPFILE;

第三处看监听器状态里有没有 HTTP 相关服务注册。三处都正常还 404，重新跑一次@apxconf.sql，把 DAD 重建一遍，比继续猜快得多。

坑四：安装到一半报 ORA-01653，表空间不足

现象：apexins.sql跑到中途报ORA-01653: unable to extend table，安装中断。

原因：apex01表空间初始 100M 不够，或者建表空间时没加AUTOEXTEND ON。

解决：先给表空间加数据文件，再重新跑安装脚本：

-- 追加一个数据文件，临时救急 ALTER TABLESPACE apex01 ADD DATAFILE '/d01/oracle/ORCL/db/apps_st/data/apex01_02.dbf' SIZE 200M AUTOEXTEND ON NEXT 100M MAXSIZE 2000M;

中断的安装不能就地续跑，得先清理残留再重来。这也是为什么我在 2.2 节强调AUTOEXTEND ON和MAXSIZE一起写——只开自动扩展不设上限，磁盘被吃满的时候影响的是整个数据库实例，不只是 APEX。

坑五：页面能开，但中文全是问号或空白

现象：装完中文语言包，界面部分文字还是英文，或者出现乱码方块。

原因：两种情况。一是语言包脚本执行了但实例默认语言没改；二是数据库字符集本身不支持中文，语言包只能翻译界面文字，改不了存储编码。

解决：先查字符集：

-- 字符集不是 ZHS16GBK / AL32UTF8 这类中文字符集时，界面中文一定有问题 SELECT parameter, value FROM nls_database_parameters WHERE parameter = 'NLS_CHARACTERSET';

字符集没问题的话，进 APEX 管理界面把实例默认语言和应用语言都改成中文，改完清浏览器缓存再看。字符集本身不对就只能重建库，这个代价要在建库阶段就想清楚，装完再发现基本没有低成本的解法。

6. 装完怎么验证：从 apex_admin 登录到一张 Tabular Form 提交成功

环境装完，"能打开页面"不算验证通过。我判断一套 APEX 是否真的可用，会走一条最小闭环：ADMIN 登录 → 建空间 → 建应用 → 建一个基于视图的 Tabular Form → 改一行数据点提交 → 回数据库查结果。这条链路把认证、Schema 绑定、页面渲染、DML 提交四个环节全串起来了，任何一环有问题都会在这一步暴露。

先在业务 Schema 下准备两张表和一个视图：

-- 主表 + 类别表，APEX 页面基于视图做 Tabular Form CREATE TABLE biz_user ( user_id VARCHAR2(50), login_name VARCHAR2(50), class_id NUMBER ); CREATE TABLE biz_class ( class_id NUMBER, class_name VARCHAR2(50) ); CREATE OR REPLACE VIEW v_user_class AS SELECT u.user_id, u.login_name, c.class_name FROM biz_user u, biz_class c WHERE c.class_id = u.class_id;

然后在应用里新建页面，Data Source 选V_USER_CLASS，类型选 Tabular Form，把LOGIN_NAME和CLASS_NAME两列设为可编辑，加一个 Apply Change 按钮，按钮上挂一个 Process 做更新。跑起来之后改一行LOGIN_NAME，点提交，再回数据库查：

-- 提交成功的话这里能看到新值，查不到就是 Process 没生效 SELECT * FROM biz_user WHERE user_id = '1001';

验证清单我一般按这张表逐项过：

最容易漏的是最后一项：页面看着能改、点了也不报错，但数据库里没变。多数情况是 Process 没绑到按钮上，或者 Tabular Form 的 "Apply Changes" 走的是内置的 MRU 流程，你自己加的 Process 排在它后面。遇到这种，把 Process 的执行顺序和触发点调一下就好。

从那以后我每次搭完一套 APEX 环境，都强制先拿 ADMIN 登一次、再查一遍dba_users里有没有APEX%的老用户，最后走一遍上面这条最小闭环——环境这东西，装完当场不验，等到业务方来用的时候再炸，排查成本是十倍。希望帮到你。

本文还有配套的精品资源，点击获取