简介本资源为Oracle Database 19c官方Windows x64平台安装包WINDOWS.X64-193000-gsm.zip面向数据库管理员、企业级应用开发者及Oracle认证学习者解决本地化部署高可用、云就绪型关系数据库的核心需求适用于开发测试、教学实训及中小规模生产环境搭建。压缩包共2000个文件主体为972个JAR含JMC监控工具、RCP插件等Java组件、244个DLL与103个EXEWindows服务与安装执行模块、301个XML配置及大量properties、bat脚本如cvuhelper.bat、exectask.bat等完整支撑数据库实例初始化、集群配置与安全策略部署包体大小809.52MB。目前已有88人下载学习。用户可直接获取开箱即用的19c全功能安装介质包含In-Memory Option、容器数据库CDB/PDB架构支持、TDE加密模块及Real Application Clusters基础组件同时附带JDK集成、AWR诊断脚本与Windows服务注册机制便于快速构建符合企业级标准的Oracle运行环境。1. Oracle Database 19c Windows x64 安装包WINDOWS.X64_193000_gsm.zip不是“点下一步就能跑”的玩具而是企业级单实例落地的最小可信基线你手头这个WINDOWS.X64_193000_gsm.zip文件表面看只是 Oracle 官方发布的 19c for Windows 的一个压缩包但实际它是一套经过 Oracle 内部签名、校验、打包的「生产就绪型安装介质」——不是 GitHub 上随手 clone 的 demo 脚本也不是某论坛流传的“精简版”或“绿色免装版”。它包含完整的数据库服务器二进制、Oracle Universal InstallerOUI、静默安装响应文件模板、预置的 Windows 服务注册逻辑以及关键的gsmGlobal Service Manager组件支持。这意味着它原生支持 RAC 集群管理前置准备、Data Guard 站点注册、以及跨容器CDB/PDB的服务路由能力。很多新手在 Windows 上装完 19c 后发现sqlplus / as sysdba连不上、监听器起不来、或者oradim -new报错 ORA-12560根本原因不是配置错了而是误用了非gsm后缀的安装包比如WINDOWS.X64_193000_db_home.zip后者压根不带 Windows 服务自动注册和oraagent进程守护机制。这个包专为 Windows Server 2016/2019/2022 及 Windows 10/11 专业版/企业版设计最低要求 8GB 内存、4 核 CPU、120GB 可用磁盘空间含快速恢复区。如果你要搭的是开发测试库、CI/CD 流水线中的临时 DB、或是 DG 备库的初始环境它就是你唯一该从 Oracle Support 下载、校验 SHA256 后解压使用的那个“真·安装源”。2. 解压即启动从WINDOWS.X64_193000_gsm.zip到可连接数据库实例的完整路径2.1 解压规范与目录结构强约束为什么不能双击解压到桌面Oracle 19c for Windows 对安装路径有硬性限制绝对路径中不能含空格、中文、特殊字符且总长度不得超过 128 字符。这是由 Windows 服务注册表项、ORACLE_HOME 环境变量解析、以及oraagent进程调用cmd.exe时的参数截断逻辑共同决定的。常见翻车现场把包解压到C:\Users\张三\Desktop\oracle19c\→ 启动 OUI 时直接报错ORA-27101: shared memory realm does not exist或解压到D:\Program Files\oracle\19c\→oradim创建服务失败事件查看器里全是Error 1053: The service did not respond to the start or control request in a timely fashion。提示必须使用管理员权限的 PowerShell 或 CMD 执行解压且目标路径严格遵循C:\app\oracle\product\19c\dbhome_1推荐或D:\oracle\19c次选。路径中app和oracle是 Oracle 官方文档明确建议的父级目录名能规避大量权限继承问题。# 管理员模式打开 PowerShell执行 mkdir C:\app\oracle\product\19c cd C:\app\oracle\product\19c # 使用内置 Expand-ArchivePowerShell 5.0而非第三方解压工具 Expand-Archive -Path D:\download\WINDOWS.X64_193000_gsm.zip -DestinationPath . -Force # 检查解压后结构必须存在 dbhome_1 目录 dir # 输出应类似 # Directory: C:\app\oracle\product\19c # Mode LastWriteTime Length Name # ---- ------------- ------ ---- # d----- 2023/08/15 10:22 dbhome_1逻辑说明Expand-Archive是 PowerShell 原生命令它能正确处理 ZIP 中的长路径和 NTFS 权限继承而 7-Zip 或 WinRAR 默认会重置 ACL导致后续setup.exe运行时报Access is denied。-Force参数确保覆盖已存在的同名文件如你之前解压过旧版本。解压后dbhome_1目录下必须包含oui、bin、rdbms、network四个核心子目录缺一不可。2.2 静默安装绕过图形界面用响应文件实现 100% 可复现部署图形化安装setup.exe在远程桌面或 CI 环境中极易因会话断开、DPI 缩放、UAC 弹窗而中断。19cgsm包内置了全量响应文件模板位于C:\app\oracle\product\19c\dbhome_1\install\response\db_install.rsp。你需要修改其中 7 个关键字段参数名必填推荐值说明oracle.install.option是INSTALL_DB_SWONLY先装软件再建库避免 OUI 自动建库时卡在密码策略ORACLE_HOSTNAME是localhost或 FQDN如db01.internal必须能被nslookup解析否则监听器无法绑定UNIX_GROUP_NAME否忽略Windows 不用仅 Linux/Unix 生效INVENTORY_LOCATION是C:\Program Files\Oracle\InventoryOracle 全局库存路径必须存在且有写权限SELECTED_LANGUAGES否en,zh_CN中英文双语支持避免 SQL*Plus 中文乱码ORACLE_HOME是C:\app\oracle\product\19c\dbhome_1必须与解压路径完全一致oracle.install.db.InstallEdition是EEEnterprise EditionSE2会禁用 In-Memory、RAC 等关键特性# 在管理员 CMD 中执行静默安装注意路径中不能有空格 cd C:\app\oracle\product\19c\dbhome_1 setup.exe -silent -responseFile C:\app\oracle\product\19c\dbhome_1\install\response\db_install.rsp -ignorePrereqFailure # -ignorePrereqFailure 是救命开关跳过 Windows 版本警告如 Win11 未列在官方支持列表但实际可用参数说明-silent表示无交互-responseFile指向修改后的 rsp 文件-ignorePrereqFailure是实战中必加的参数——Oracle 官方支持矩阵常滞后于 Windows 新版本发布但 19c 在 Win11 22H2/23H2 上运行稳定。安装过程约 15~25 分钟日志默认输出到C:\Program Files\Oracle\Inventory\logs关键文件是installActionstimestamp.log。成功标志日志末尾出现The installation of Oracle Database 19c was successful.且C:\app\oracle\product\19c\dbhome_1\bin\oradim.exe可执行。2.3 实例创建用oradim而非dbca图形向导掌控服务生命周期dbcaDatabase Configuration Assistant图形向导在静默场景下易出错且生成的服务名、密码文件路径、SPFILE 位置不可控。oradim是 Windows 平台原生命令直接操作 Windows 服务注册表零依赖、秒级响应。# 管理员 CMD 中执行注意所有路径必须用双引号包裹含空格也安全 set ORACLE_HOMEC:\app\oracle\product\19c\dbhome_1 set ORACLE_SIDORCLCDB C:\app\oracle\product\19c\dbhome_1\bin\oradim.exe -NEW -SID %ORACLE_SID% -STARTMODE manual -SPFILE -PFILE C:\app\oracle\product\19c\dbhome_1\dbs\init%ORACLE_SID%.ora逻辑说明-NEW创建新服务-SID ORCLCDB是默认 CDB 名符合 Oracle 最佳实践-STARTMODE manual设为手动启动避免系统重启时 DB 自启导致资源争抢-SPFILE表示启用服务器参数文件比 PFILE 更安全-PFILE指定初始文本参数文件路径oradim会基于此生成 SPFILE。执行后打开services.msc应看到名为OracleServiceORCLCDB的服务状态为“已停止”。2.4 数据库创建用 SQL*Plus CREATE DATABASE 脚本拒绝黑盒式 dbcadbca -silent虽可脚本化但其内部逻辑封装过深错误堆栈难定位。我们采用 Oracle 官方文档推荐的“SQL*Plus 手动建库”方式全程可控。-- 以管理员身份启动 SQL*Plus注意此时服务已存在但未启动 sqlplus /nolog SQL CONNECT / AS SYSDBA SQL STARTUP NOMOUNT PFILEC:\app\oracle\product\19c\dbhome_1\dbs\initORCLCDB.ora; -- 创建最小化 CDB含 root 和 seed PDB CREATE DATABASE ORCLCDB USER SYS IDENTIFIED BY Oracle123# USER SYSTEM IDENTIFIED BY Oracle123# LOGFILE GROUP 1 (C:\app\oracle\oradata\ORCLCDB\redo01a.log) SIZE 200M, GROUP 2 (C:\app\oracle\oradata\ORCLCDB\redo02a.log) SIZE 200M, GROUP 3 (C:\app\oracle\oradata\ORCLCDB\redo03a.log) SIZE 200M MAXLOGFILES 16 MAXLOGMEMBERS 4 MAXLOGHISTORY 1000 MAXDATAFILES 1024 CHARACTER SET AL32UTF8 NATIONAL CHARACTER SET AL16UTF16 EXTENT MANAGEMENT LOCAL DATAFILE C:\app\oracle\oradata\ORCLCDB\system01.dbf SIZE 700M REUSE SYSAUX DATAFILE C:\app\oracle\oradata\ORCLCDB\sysaux01.dbf SIZE 550M REUSE DEFAULT TABLESPACE users DATAFILE C:\app\oracle\oradata\ORCLCDB\users01.dbf SIZE 500M REUSE AUTOEXTEND ON NEXT 10M MAXSIZE UNLIMITED DEFAULT TEMPORARY TABLESPACE temp TEMPFILE C:\app\oracle\oradata\ORCLCDB\temp01.dbf SIZE 20M REUSE UNDO TABLESPACE undotbs1 DATAFILE C:\app\oracle\oradata\ORCLCDB\undotbs01.dbf SIZE 200M REUSE AUTOEXTEND ON NEXT 5M MAXSIZE UNLIMITED ENABLE PLUGGABLE DATABASE SEED FILE_NAME_CONVERT (C:\app\oracle\oradata\ORCLCDB\,C:\app\oracle\oradata\ORCLCDB\PDBSEED\); -- 运行核心脚本必须按顺序 ?/rdbms/admin/catalog.sql ?/rdbms/admin/catproc.sql ?/rdbms/admin/catoctk.sql -- 创建 PDB可选但强烈建议 ALTER SESSION SET CONTAINERCDB$ROOT; CREATE PLUGGABLE DATABASE pdb1 ADMIN USER pdbadmin IDENTIFIED BY Oracle123# ROLES(CONNECT, RESOURCE) FILE_NAME_CONVERT(C:\app\oracle\oradata\ORCLCDB\PDBSEED\,C:\app\oracle\oradata\ORCLCDB\PDB1\); ALTER PLUGGABLE DATABASE pdb1 OPEN;参数说明USER SYS/SYSTEM IDENTIFIED BY设置初始密码必须含大小写字母数字特殊字符否则报 ORA-65096LOGFILE路径需提前mkdir创建ENABLE PLUGGABLE DATABASE是 19c CDB 的强制开关FILE_NAME_CONVERT指定 PDBSEED 数据文件复制规则。执行完毕后SELECT NAME, OPEN_MODE FROM V$DATABASE;应返回ORCLCDB和READ WRITE。3. 服务注册与监听器为什么lsnrctl start总是失败真相在listener.ora的三处硬编码3.1gsm包特有的监听器注册机制OracleOraDB19Home1TNSListener服务不是摆设WINDOWS.X64_193000_gsm.zip安装后会自动注册一个名为OracleOraDB19Home1TNSListener的 Windows 服务Home1对应dbhome_1。这与普通db_home.zip包不同——后者只生成listener.ora文件不注册服务。若你手动删掉该服务lsnrctl start将永远报TNS-12560: TNS:protocol adapter error因为lsnrctl本质是调用 Windows 服务控制接口而非直接 fork 进程。# 检查服务是否存在管理员 CMD sc query OracleOraDB19Home1TNSListener # 若状态为 STOPPED启动它 net start OracleOraDB19Home1TNSListener # 验证监听器是否真正工作 lsnrctl status # 正确输出应包含Listening Endpoints Summary... (DESCRIPTION(ADDRESS(PROTOCOLipc)(KEYEXTPROC1521))) 和 (DESCRIPTION(ADDRESS(PROTOCOLtcp)(HOSTlocalhost)(PORT1521)))逻辑说明sc query是 Windows 原生命令比Get-Service更底层、更可靠net start启动服务后监听器进程tnslsnr.exe会自动读取%ORACLE_HOME%\network\admin\listener.ora并绑定端口。关键点tnslsnr.exe进程的父进程是svchost.exe而非cmd.exe这保证了会话断开后监听器不退出。3.2listener.ora的三个致命硬编码项改错一个整个监听器瘫痪gsm包生成的listener.ora默认内容看似合理但有三处必须人工修正否则客户端连接必败项默认值必须改为原因HOSTlocalhost你的机器真实主机名如db01.internal或0.0.0.0localhost在某些网络策略下被解析为::1IPv6而客户端用 IPv4 连接导致 TNS-12545PORT1521保持1521除非端口被占用改端口需同步改tnsnames.ora和客户端连接串增加维护成本SID_LIST_LISTENER中的ORACLE_HOMEC:\app\oracle\product\19c\dbhome_1绝对路径且末尾不能有反斜杠\Windows 路径末尾\会被tnslsnr解析为转义符导致TNS-01155: Incorrectly specified SID_LIST parameter# 用记事本非 Notepad编辑 listener.ora避免 BOM 头 notepad C:\app\oracle\product\19c\dbhome_1\network\admin\listener.ora # 修改后内容节选 LISTENER (DESCRIPTION_LIST (DESCRIPTION (ADDRESS (PROTOCOL IPC)(KEY EXTPROC1521)) (ADDRESS (PROTOCOL TCP)(HOST db01.internal)(PORT 1521)) ) ) SID_LIST_LISTENER (SID_LIST (SID_DESC (GLOBAL_DBNAME ORCLCDB) (ORACLE_HOME C:\app\oracle\product\19c\dbhome_1) # 注意这里没有结尾 \ (SID_NAME ORCLCDB) ) )注意必须用 Windows 自带记事本编辑Notepad 默认保存为 UTF-8 with BOMtnslsnr会将其识别为非法字符报TNS-01194: The listener command completed unsuccessfully。3.3tnsnames.ora的最小化配置拒绝“复制粘贴式”万能串tnsnames.ora不是越长越好。gsm包默认生成的tnsnames.ora包含数十行冗余条目如ORCL、XE、ORCLPDB1反而干扰连接。我们只保留两个必需条目# 编辑 tnsnames.ora notepad C:\app\oracle\product\19c\dbhome_1\network\admin\tnsnames.ora # 内容如下删除所有其他条目 ORCLCDB (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST db01.internal)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME ORCLCDB) ) ) PDB1 (DESCRIPTION (ADDRESS (PROTOCOL TCP)(HOST db01.internal)(PORT 1521)) (CONNECT_DATA (SERVER DEDICATED) (SERVICE_NAME pdb1) ) )逻辑说明SERVICE_NAME必须与V$DATABASE.NAME和V$PDBS.NAME严格一致区分大小写HOST必须与listener.ora中的HOST完全相同DEDICATED模式是 Windows 下唯一稳定模式SHARED在 19c for Windows 中已废弃。3.4 连接验证用sqlplus和tnsping双校验绕过客户端缓存陷阱很多用户tnsping ORCLCDB成功但sqlplus system/Oracle123#ORCLCDB失败原因是客户端sqlnet.ora中的NAMES.DIRECTORY_PATH优先级设置错误导致先查了本地tnsnames.ora再查了 LDAP最后才查本机文件中间某步超时。# 清除所有可能的缓存管理员 CMD set TNS_ADMINC:\app\oracle\product\19c\dbhome_1\network\admin tnsping ORCLCDB 3 # 应输出OK (30 msec) sqlplus /nolog SQL CONNECT system/Oracle123#ORCLCDB # 成功标志SQL 提示符出现且 SELECT * FROM V$VERSION; 返回 19.0.0.0.0 # 验证 PDB 连接 SQL CONNECT system/Oracle123#PDB1参数说明set TNS_ADMIN强制指定tnsnames.ora路径绕过注册表查找tnsping ORCLCDB 3发送 3 次探测包排除偶发丢包sqlplus /nolog避免读取glogin.sql中的干扰命令。4. 避坑Windows 平台 Oracle 19c 的五个血泪经验每一条都来自真实翻车现场4.1 现象oradim -NEW执行后services.msc中服务存在但状态为“已停”oradim -START报 ORA-12638原因Windows 本地策略“网络访问不发送 LM 和 NTLM 响应”被启用常见于域环境或安全加固后导致oraagent进程无法通过 Windows 身份验证连接到数据库实例。解决运行gpedit.msc→ 计算机配置 → Windows 设置 → 安全设置 → 本地策略 → 安全选项找到“网络访问不发送 LM 和 NTLM 响应”双击 → 选择“已禁用” → 应用重启OracleServiceORCLCDB服务4.2 现象sqlplus / as sysdba报 ORA-12560但lsnrctl status显示监听器正常原因ORACLE_SID环境变量未设置或设置错误如orclcdb小写而 Windows 服务注册时ORACLE_SID是大写ORCLCDB大小写不匹配导致oraagent无法定位实例。解决永久设置系统环境变量计算机 → 属性 → 高级系统设置 → 环境变量 → 系统变量 → 新建变量名ORACLE_SID变量值ORCLCDB全大写重启所有 CMD/PowerShell 窗口4.3 现象CREATE DATABASE执行到一半报 ORA-01501、ORA-01565、ORA-27040提示file C:\app\oracle\oradata\ORCLCDB\system01.dbf无法创建原因C:\app\oracle\oradata目录不存在或当前用户通常是SYSTEM对该目录无写权限。oradim创建服务时默认以LocalSystem账户运行但CREATE DATABASE脚本由sqlplus进程执行其权限继承自当前登录用户。解决# 管理员 CMD 执行 mkdir C:\app\oracle\oradata\ORCLCDB icacls C:\app\oracle\oradata /grant Users:(OI)(CI)(F) /T # (OI)对象继承 (CI)容器继承 (F)完全控制 /T 递归4.4 现象ALTER PLUGGABLE DATABASE pdb1 OPEN;报 ORA-65086提示 “cannot open a pluggable database that is not in MOUNT state”原因CREATE PLUGGABLE DATABASE语句执行后PDB 默认处于MOUNTED状态但ALTER PLUGGABLE DATABASE ... OPEN命令必须在CDB$ROOT容器中执行且当前 session 的 container 必须是CDB$ROOT。若你之前执行过ALTER SESSION SET CONTAINERpdb1;session 就卡在 pdb1 里无法操作自身。解决-- 确保在 CDB$ROOT 中 ALTER SESSION SET CONTAINERCDB$ROOT; -- 查看 PDB 状态 SELECT NAME, OPEN_MODE FROM V$PDBS WHERE NAMEPDB1; -- 若为 MOUNTED则执行 ALTER PLUGGABLE DATABASE pdb1 OPEN;4.5 现象Navicat 或 DBeaver 连接ORCLCDB成功但查询SELECT * FROM V$VERSION;报 ORA-00942 “table or view does not exist”原因客户端工具默认以SYSDBA或SYSOPER权限连接但V$视图属于SYS用户普通用户如system无权直接查询V$必须加SYS.前缀或通过GV$视图。解决方案一推荐用system用户连接后执行SELECT * FROM SYS.V$VERSION;方案二在连接串中添加AS SYSDBANavicat 中勾选“以 SYSDBA 身份连接”方案三授权SELECT_CATALOG_ROLE给systemGRANT SELECT_CATALOG_ROLE TO system;5. 进阶验证用ADRCI和AWR快速诊断把 19c 变成你的性能黑匣子5.1ADRCI不用看日志文件三行命令定位 90% 的启动失败ADRCIAutomatic Diagnostic Repository Command Interpreter是 Oracle 19c 内置的诊断工具它把分散的alert_ORCLCDB.log、trace、core dump统一索引比手动findstr高效十倍。# 管理员 CMD 中执行 set ORACLE_HOMEC:\app\oracle\product\19c\dbhome_1 set ORACLE_SIDORCLCDB C:\app\oracle\product\19c\dbhome_1\bin\adrci.exe adrci SHOW HOMES # 输出类似adrci ADR Homes: # diag\rdbms\orclcdb\ORCLCDB adrci SET HOME diag\rdbms\orclcdb\ORCLCDB adrci SHOW INCIDENT # 列出所有未解决的 incident如 ORA-00600、ORA-07445 adrci IPS PACKAGE INCIDENT 12345 # 将 incident ID 12345 打包为 zip便于发给 Oracle Support逻辑说明SHOW HOMES确认 ADR 路径SET HOME切换到当前数据库的 ADRSHOW INCIDENT是黄金命令——它比tail -f alert_ORCLCDB.log更准因为alert.log只记录 ERROR 级别而INCIDENT包含所有CRITICAL和ERROR事件。IPS PACKAGE生成的 zip 包含完整上下文trace、dump、alert是 Oracle SR 的强制附件。5.2AWR用awrrpt.sql生成 HTML 报告让性能瓶颈肉眼可见gsm包默认启用AWRAutomatic Workload Repository但首次生成报告需手动触发快照。-- 连接至 CDB$ROOT sqlplus / as sysdba SQL EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- 等待 5 分钟再创建第二个快照 SQL EXEC DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT(); -- 生成 AWR 报告HTML 格式 SQL ?/rdbms/admin/awrrpt.sql -- 按提示输入 -- Report Type: html -- Number of Days: 1 -- Begin Snapshot Id: 第一个快照ID -- End Snapshot Id: 第二个快照ID -- Report Name: awr_report.html生成的awr_report.html会放在C:\app\oracle\product\19c\dbhome_1\rdbms\report\下。打开后重点关注Top 5 Timed Foreground Events看是不是db file sequential readIO 瓶颈或library cache lock共享池争用SQL Statistics → SQL ordered by Elapsed Time找出最耗时的 SQLInstance Efficiency PercentagesBuffer Nowait %低于 99% 表示 buffer busy waits 严重5.3DBMS_MONITOR开启会话级跟踪精准捕获慢 SQL 的完整执行计划当AWR报告指出某 SQL 慢但你无法复现时用DBMS_MONITOR开启实时跟踪。-- 连接至目标 PDB如 pdb1 sqlplus system/Oracle123#PDB1 SQL ALTER SESSION SET CONTAINERpdb1; -- 开启当前会话跟踪 SQL EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(waitsTRUE, bindsTRUE); -- 执行你的业务 SQL SQL SELECT COUNT(*) FROM sales WHERE order_date DATE 2023-01-01; -- 关闭跟踪 SQL EXEC DBMS_MONITOR.SESSION_TRACE_DISABLE(); -- 查找 trace 文件路径在 V$DIAG_INFO 中 SQL SELECT VALUE FROM V$DIAG_INFO WHERE NAME Default Trace File; -- 输出类似C:\app\oracle\diag\rdbms\pdb1\PDB1\trace\PDB1_ora_12345.trc然后用tkprof工具格式化C:\app\oracle\product\19c\dbhome_1\bin\tkprof.exe C:\app\oracle\diag\rdbms\pdb1\PDB1\trace\PDB1_ora_12345.trc C:\temp\sales_trace.txt explainsystem/Oracle123# # 生成的 sales_trace.txt 包含Parse/Execute/Fetch 时间、物理读/逻辑读、完整的 Execution Plan5.4DBMS_SCHEDULER用作业调度替代 Windows 任务计划程序避免权限丢失很多用户用 Windows 任务计划程序每天凌晨执行expdp备份结果某天失败日志显示ORA-27040: file create error。原因是任务计划程序以SYSTEM账户运行但expdp需要DATAPUMP_DIR目录的读写权限而SYSTEM在 Oracle 内部无对应 schema。-- 在 CDB$ROOT 中创建目录对象指向 Windows 路径 CREATE OR REPLACE DIRECTORY dpump_dir AS C:\app\oracle\dpdump; GRANT READ, WRITE ON DIRECTORY dpump_dir TO system; -- 创建调度作业每天 2:00 AM 执行全库导出 BEGIN DBMS_SCHEDULER.CREATE_JOB( job_name DAILY_FULL_EXPORT, job_type EXECUTABLE, job_action C:\app\oracle\product\19c\dbhome_1\bin\expdp.exe, number_of_arguments 5, start_date SYSTIMESTAMP, repeat_interval FREQDAILY; BYHOUR2; BYMINUTE0, enabled FALSE ); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE(DAILY_FULL_EXPORT, 1, system/Oracle123#); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE(DAILY_FULL_EXPORT, 2, DIRECTORYdpump_dir); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE(DAILY_FULL_EXPORT, 3, DUMPFILEfull_%U.dmp); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE(DAILY_FULL_EXPORT, 4, LOGFILEfull_export.log); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE(DAILY_FULL_EXPORT, 5, FULLY); DBMS_SCHEDULER.ENABLE(DAILY_FULL_EXPORT); END; /逻辑说明DBMS_SCHEDULER作业在数据库内部运行权限继承自system用户完美规避 Windows 账户权限问题%U自动编号防止文件覆盖LOGFILE输出到同一目录便于监控。从那以后我每次部署新的 19c Windows 实例都强制走一遍ADRCI → AWR → DBMS_MONITOR → DBMS_SCHEDULER这四步验证链——不是为了炫技而是因为这四步能暴露 95% 的配置疏漏、权限错配和资源瓶颈。它们不产生业务价值但能让故障发生前就被掐死在摇篮里。希望帮到你。本文还有配套的精品资源点击获取