简介：本资源为Oracle Database 19c官方Windows x64平台安装包（WINDOWS.X64-193000-gsm.zip），面向数据库管理员、企业级应用开发者及Oracle认证学习者，解决本地化部署高可用、云就绪型关系数据库的核心需求，适用于开发测试、教学实训及中小规模生产环境搭建。压缩包共2000个文件，主体为972个JAR（含JMC监控工具、RCP插件等Java组件）、244个DLL与103个EXE（Windows服务与安装执行模块）、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 Installer（OUI）、静默安装响应文件模板、预置的 Windows 服务注册逻辑，以及关键的gsm（Global 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-Archive（PowerShell 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\Inventory | Oracle 全局库存路径，必须存在且有写权限 |
SELECTED_LANGUAGES | 否 | en,zh_CN | 中英文双语支持，避免 SQL*Plus 中文乱码 |
ORACLE_HOME | 是 | C:\app\oracle\product\19c\dbhome_1 | 必须与解压路径完全一致 |
oracle.install.db.InstallEdition | 是 | EE | Enterprise Edition，SE2会禁用 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，关键文件是installActions<timestamp>.log。成功标志：日志末尾出现The installation of Oracle Database 19c was successful.且C:\app\oracle\product\19c\dbhome_1\bin\oradim.exe可执行。
2.3 实例创建：用oradim而非dbca图形向导，掌控服务生命周期
dbca（Database Configuration Assistant）图形向导在静默场景下易出错，且生成的服务名、密码文件路径、SPFILE 位置不可控。oradim是 Windows 平台原生命令，直接操作 Windows 服务注册表，零依赖、秒级响应。
# 管理员 CMD 中执行（注意：所有路径必须用双引号包裹，含空格也安全） set ORACLE_HOME=C:\app\oracle\product\19c\dbhome_1 set ORACLE_SID=ORCLCDB 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 脚本，拒绝黑盒式 dbca
dbca -silent虽可脚本化，但其内部逻辑封装过深，错误堆栈难定位。我们采用 Oracle 官方文档推荐的“SQL*Plus 手动建库”方式，全程可控。
-- 以管理员身份启动 SQL*Plus（注意：此时服务已存在但未启动） sqlplus /nolog SQL> CONNECT / AS SYSDBA SQL> STARTUP NOMOUNT PFILE='C:\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 CONTAINER=CDB$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-65096）；LOGFILE路径需提前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=(PROTOCOL=ipc)(KEY=EXTPROC1521))) 和 (DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=localhost)(PORT=1521)))逻辑说明：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默认内容看似合理，但有三处必须人工修正，否则客户端连接必败：
| 项 | 默认值 | 必须改为 | 原因 |
|---|---|---|---|
HOST | localhost | 你的机器真实主机名（如db01.internal）或0.0.0.0 | localhost在某些网络策略下被解析为::1（IPv6），而客户端用 IPv4 连接导致 TNS-12545 |
PORT | 1521 | 保持1521（除非端口被占用） | 改端口需同步改tnsnames.ora和客户端连接串，增加维护成本 |
SID_LIST_LISTENER中的ORACLE_HOME | C:\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 BOM，
tnslsnr会将其识别为非法字符，报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_ADMIN=C:\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 CONTAINER=pdb1;，session 就卡在 pdb1 里，无法操作自身。
解决：
-- 确保在 CDB$ROOT 中 ALTER SESSION SET CONTAINER=CDB$ROOT; -- 查看 PDB 状态 SELECT NAME, OPEN_MODE FROM V$PDBS WHERE NAME='PDB1'; -- 若为 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 SYSDBA（Navicat 中勾选“以 SYSDBA 身份连接”） - 方案三：授权
SELECT_CATALOG_ROLE给system：GRANT SELECT_CATALOG_ROLE TO system;
5. 进阶验证：用ADRCI和AWR快速诊断，把 19c 变成你的性能黑匣子
5.1ADRCI：不用看日志文件，三行命令定位 90% 的启动失败
ADRCI（Automatic Diagnostic Repository Command Interpreter）是 Oracle 19c 内置的诊断工具，它把分散的alert_ORCLCDB.log、trace、core dump统一索引，比手动findstr高效十倍。
# 管理员 CMD 中执行 set ORACLE_HOME=C:\app\oracle\product\19c\dbhome_1 set ORACLE_SID=ORCLCDB 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切换到当前数据库的 ADR；SHOW 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包默认启用AWR（Automatic 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 read（IO 瓶颈）或library cache lock（共享池争用） - SQL Statistics → SQL ordered by Elapsed Time：找出最耗时的 SQL
- Instance Efficiency Percentages：
Buffer Nowait %低于 99% 表示 buffer busy waits 严重
5.3DBMS_MONITOR：开启会话级跟踪，精准捕获慢 SQL 的完整执行计划
当AWR报告指出某 SQL 慢，但你无法复现时，用DBMS_MONITOR开启实时跟踪。
-- 连接至目标 PDB（如 pdb1） sqlplus system/Oracle123#@PDB1 SQL> ALTER SESSION SET CONTAINER=pdb1; -- 开启当前会话跟踪 SQL> EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(waits=>TRUE, binds=>TRUE); -- 执行你的业务 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 explain=system/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 => 'FREQ=DAILY; BYHOUR=2; BYMINUTE=0', enabled => FALSE ); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('DAILY_FULL_EXPORT', 1, 'system/Oracle123#'); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('DAILY_FULL_EXPORT', 2, 'DIRECTORY=dpump_dir'); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('DAILY_FULL_EXPORT', 3, 'DUMPFILE=full_%U.dmp'); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('DAILY_FULL_EXPORT', 4, 'LOGFILE=full_export.log'); DBMS_SCHEDULER.SET_JOB_ARGUMENT_VALUE('DAILY_FULL_EXPORT', 5, 'FULL=Y'); DBMS_SCHEDULER.ENABLE('DAILY_FULL_EXPORT'); END; /逻辑说明：DBMS_SCHEDULER作业在数据库内部运行，权限继承自system用户，完美规避 Windows 账户权限问题；%U自动编号，防止文件覆盖；LOGFILE输出到同一目录，便于监控。
从那以后我每次部署新的 19c Windows 实例，都强制走一遍ADRCI → AWR → DBMS_MONITOR → DBMS_SCHEDULER这四步验证链——不是为了炫技，而是因为这四步能暴露 95% 的配置疏漏、权限错配和资源瓶颈。它们不产生业务价值，但能让故障发生前就被掐死在摇篮里。希望帮到你。
本文还有配套的精品资源，点击获取
