Huigr王自己干Oracle DBA也有十来年了，平时跟各种生产环境打交道，发现很多刚入行或者从开发转过来的朋友，最头疼的不是SQL写不出来，而是面对一台装好的Oracle数据库，不知道该敲什么命令去查状态、做巡检、处理故障。网上搜“oracle常用命令”出来的东西太零散，要么是纯语法堆砌，要么是过时的老版本写法，真正能直接用在生产环境里的干货反而被淹没了。
这篇东西我打算换个思路，不按命令字典的方式平铺，而是从DBA真实的工作场景出发——“我要看数据库活没活”“我要查谁在拖慢系统”“我要扩容一个表空间”“我要迁移一套库”——每个场景把最核心的命令、参数含义、实际输出怎么理解，以及我踩过的坑都写清楚。适合刚接手Oracle维护的开发、运维同学，也适合准备OCP考试或者做等保、巡检的同行参考。内容以11g/12c/19c为主，这几代版本命令兼容性最好，生产环境存量也最大。
1. 会话与实例状态排查：先确认数据库到底醒没醒
接手任何一套Oracle系统，第一件事永远是确认实例和数据库本身的状态。DBA最怕的就是“用户说库连不上”，结果一查是监听挂了、实例起来了但数据库没mount、或者ASM磁盘组出问题，表象一模一样，根因差着十万八千里。所以我习惯按一条固定的链路去排查，这套链路我用到现在没出过岔子。
1.1 从操作系统到监听器的三层状态确认
先在操作系统层面确认进程还活着，这是最底层的事实。Linux下用下面这条命令看Oracle相关进程，注意别用ps -ef | grep oracle就完事，因为grep自己也会匹配到oracle关键字，导致结果里出现一条假的进程行，初学的时候我被这个误导过好几次。
bash复制ps -ef | grep ora_ | grep -v grep
这里grep -v grep是必须的，把grep进程本身过滤掉。正常情况下你会看到一堆以ora_开头的后台进程，比如ora_pmon_、ora_smon_、ora_dbw0_、ora_lgwr_、ora_ckpt_，分别对应进程监控、系统监控、数据库写进程、日志写进程、检查点进程。如果ora_pmon_没了，基本可以断定实例已经崩了，后面所有命令都不用敲，直接去看alert日志找原因。
进程在，不代表客户端能连上，还要看监听器状态。监听器是数据库对外的大门，门没开，后端服务再好也白搭。
bash复制lsnrctl status
lsnrctl services
lsnrctl status会显示监听端口（默认1521）、监听的实例名、服务名，以及“Services Summary”部分每个服务当前有多少个连接。看到"DEDICATED" established字样的计数就说明有客户端正连着。这里有个常用技巧：如果实例刚启动但监听里还看不到它，说明动态注册还没完成，可以手动触发注册。
sql复制SQL> alter system register;
这条命令强制实例向监听器重新注册，省得干等一分钟。至于lsnrctl services，它的信息更细，能看到每个服务对应多少个实例、每个实例有多少连接，排查多实例环境时很有用。
1.2 进入实例内部：v$视图才是DBA的主战场
外层确认完之后，就该进到数据库内部了。SQL*Plus连进去是起点，但我见过太多人连进去之后只会敲select * from tab;，这不行。DBA要养成一个习惯：用自己的管理员账号连，或者用操作系统认证连本地库。
bash复制sqlplus / as sysdba
如果你有sysdba权限，这种方式在数据库服务器本地直连最省事，不需要密码，走的是操作系统认证。Windows下需要你当前Windows用户属于ORA_DBA组，Linux下需要属于dba组。
进去之后先看实例状态，顺序很重要，千万别跳。
sql复制SQL> select instance_name, status, database_status, version, host_name from v$instance;
这里status字段如果是OPEN，说明实例已经正常打开，可以对外服务。如果是MOUNTED或STARTED，说明实例起来了，但数据库没打开，这种情况通常是做恢复或者在等待手工alter database open;。database_status如果是ACTIVE也正常，如果是SUSPENDED或者NEED RECOVERY，那就得赶紧查原因了。
接着看数据库整体的打开状态和当前时间，这步有时候会被忽略，但其实很重要——很多排查场景需要先建立“当前是什么时间点”的基准。
sql复制SQL> select name, open_mode, created, current_scn from v$database;
current_scn是系统当前的SCN号，做恢复、闪回查询、分析日志时都需要拿它当基准。open_mode应该是READ WRITE，如果看到READ ONLY或者MOUNTED，说明库的打开模式不对，检查一下是不是有人改过配置或者做了一半恢复。
最后是归档模式，这个必须查，生产库不开归档等于把命门交给运气。
sql复制SQL> archive log list;
我习惯每次巡检都跑一遍这条命令，确认Database log mode是Archive Mode、Automatic archival是Enabled。如果一个库跑在No Archive Mode，那这个库只能做冷备，任何热备策略、增量备份、基于时间点的恢复全都用不了。生产环境见到不开归档的库，第一建议永远是先改成归档模式再谈别的。
1.3 会话与等待事件：找到“连不上”和“跑得慢”的根因
用户报“库跑得很慢”，十有八九问题出在会话和等待事件上。DBA排查性能的第一板斧就是看当前有哪些会话、在干什么、等了多久。
sql复制SQL> select sid, serial#, username, status, sql_id, event, wait_class, seconds_in_wait
from v$session
where username is not null
order by seconds_in_wait desc;
这条命令查所有活跃会话，按等待时间倒序排，一眼就能看出哪些会话卡住了。event字段是关键，常见的enq: TX - row lock contention说明有行锁等待，多个会话在抢同一行数据；library cache lock说明有人在做DDL或者编译，把别的会话堵住了；db file sequential read说明在等单块读，通常是索引扫描；SQL*Net message from client则是正常等待，客户端没发请求过来，别被这个字段吓到。
如果status是INACTIVE但seconds_in_wait很大，说明这个会话空闲很久了，可能是应用连接池没回收，也可能是有人忘了关会话。这种会话多了会把数据库的process数占满，导致新连接进不来，这就是“库连不上”但实例看着正常的常见原因之一。
想看更细的锁信息，用下面这条：
sql复制SQL> select blocking_session, sid, serial#, wait_event_text, seconds_in_wait
from v$session
where blocking_session is not null;
blocking_session会直接告诉你是哪个会话堵住了别人。拿到这个SID之后，如果要干掉一个卡死的会话，用alter system kill session 'sid,serial#' immediate;，注意格式是sid,serial#，两个值一个都不能少，中间用逗号，外面加引号。我见过有人只写了sid不写serial，命令直接报错。如果kill之后会话还挂在那里，多半是它在等待网络或者回滚，等等再看，或者到操作系统层面kill -9对应线程，不过这招是最后手段，尽量少用。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 表空间与文件管理：扩容、监控、清理三板斧
表空间满了是DBA遇到最多的“紧急故障”，没有之一。Oracle的数据文件如果满了，业务直接报ORA-01653: unable to extend table，这个错误我几乎每个月都能在群里看到有人问。实际上，只要平时巡检做到位，提前扩容或者开自动扩展，这种故障完全可以避免。
2.1 表空间使用率怎么看才准
网上关于表空间使用率的SQL五花八门，有的算出来跟实际差很多，原因是没把autoextensible的数据文件和dba_free_space的碎片问题考虑进去。我贴一条自己改过很多次、目前在生产上实测最稳的版本：
sql复制SELECT
df.tablespace_name,
ROUND(df.total_space_gb, 2) AS total_gb,
ROUND((df.total_space_gb - fs.free_space_gb), 2) AS used_gb,
ROUND(fs.free_space_gb, 2) AS free_gb,
ROUND((df.total_space_gb - fs.free_space_gb) / df.total_space_gb * 100, 2) AS used_pct
FROM
(SELECT tablespace_name, SUM(bytes) / 1024 / 1024 / 1024 AS total_space_gb
FROM dba_data_files
GROUP BY tablespace_name) df,
(SELECT tablespace_name, SUM(bytes) / 1024 / 1024 / 1024 AS free_space_gb
FROM dba_free_space
GROUP BY tablespace_name) fs
WHERE df.tablespace_name = fs.tablespace_name
ORDER BY used_pct DESC;
这里有个细节容易踩坑：如果数据文件开了autoextensible，dba_data_files里的bytes只是当前实际大小，不是最大上限。也就是说，你把表空间“用满”了之后它还能自动扩，使用率会暂时超过100%的显示值，但数据文件到了maxbytes上限之后就会真的报错。所以更严谨的做法是同时把maxbytes也纳入计算，我把这个版本放到备用脚本里：
sql复制SELECT tablespace_name,
ROUND(SUM(bytes) / 1024 / 1024 / 1024, 2) AS current_gb,
ROUND(SUM(maxbytes) / 1024 / 1024 / 1024, 2) AS max_gb,
ROUND(SUM(bytes) / SUM(maxbytes) * 100, 2) AS max_used_pct
FROM dba_data_files
GROUP BY tablespace_name
ORDER BY max_used_pct DESC;
maxbytes是数据文件允许扩展的上限，默认可能只有32G或者更小，具体看db_block_size。比如8K块大小，一个数据文件最大一般是32G或128G，取决于平台和文件系统限制。如果某个表空间max_used_pct超过80%，建议提前扩容或者增加数据文件，别等到告警了再处理。
2.2 在线扩容的三种姿势和适用场景
表空间扩容，核心原则是一个词：online，绝不允许停机扩存储。Oracle在这方面做得比较灵活，下面三种方式我都用过，各有适用场景。
常规做法是给表空间加数据文件，这种方式适合表空间整体空间不足，且不想动现有文件的情况：
sql复制SQL> alter tablespace users add datafile '/u01/app/oracle/oradata/ORCL/users02.dbf' size 32G autoextend on next 1G maxsize 32G;
注意数据文件路径要写绝对路径，别用相对路径，不然后患无穷。autoextend on next 1G表示每次自动扩1G，maxsize 32G是上限。我习惯把next设成1G，不要设太大也不要太小，太小会导致频繁扩容触发检查点开销，太大会让单次分配时间过长。
第二种方式是直接扩展现有数据文件的大小，适合文件系统还有空间、只是当前文件大小不够的情况：
sql复制SQL> alter database datafile '/u01/app/oracle/oradata/ORCL/users01.dbf' resize 40G;
执行之前务必确认操作系统的挂载点还有足够的剩余空间。df -h看一眼，别把根目录撑爆。我在生产上吃过一次亏，没查磁盘直接resize，结果ORA-01144错误，数据文件大小超过文件系统限制，虽然没损坏数据，但折腾了半天才把文件删掉重新创建。
第三种方式是开启或修改自动扩展属性，适合那些增长不均匀、不想每次手工干预的表空间：
sql复制SQL> alter database datafile '/u01/app/oracle/oradata/ORCL/users01.dbf' autoextend on next 1G maxsize 64G;
这里要特别提醒一句，自动扩展是一把双刃剑。它确实省心，但如果数据文件无限扩下去，会把磁盘塞满，最终导致所有写操作失败，包括SYS表空间的写入，严重时可能宕库。所以生产规范里一般会设一个合理的maxsize上限，配合监控告警，这样既不会频繁报错，也不会失控。
2.3 临时表空间和undo表空间：两个容易忽略的“隐形炸弹”
有些故障不是业务表空间引起的，而是临时表空间或者undo表空间出了问题，这两个地方出问题，症状往往特别诡异。
临时表空间满了，通常报ORA-01652: unable to extend temp segment by ...，常见于大排序、大哈希连接、创建索引这类操作。排查时用手工方式看不出来，因为临时表空间有临时文件，跟数据文件不在一个视图里。
sql复制SQL> select tablespace_name, file_name, bytes/1024/1024/1024 as size_gb
from dba_temp_files;
如果发现临时文件太小，直接扩容即可，临时文件可以动态调整，不需要重启：
sql复制SQL> alter tablespace temp add tempfile '/u01/app/oracle/oradata/ORCL/temp02.dbf' size 32G;
或者直接resize现有临时文件。另外，临时表空间可以建成临时表空间组，多个临时表空间组成一个组，给用户分配组名，这样并发排序压力分散到多个文件上，能缓解争用。不过一般库用不上这种操作，除非是报表分析类大并发环境。
undo表空间的问题更隐蔽。如果undo表空间不足，会报ORA-30036: unable to extend segment by 8 in undo tablespace。查询是否够用，看v$undostat：
sql复制SQL> select tablespace_name, status, sum(bytes)/1024/1024/1024 as undo_gb
from dba_undo_extents
group by tablespace_name, status;
重点看ACTIVE状态的undo占用多少，ACTIVE表示正在被活跃事务使用的undo，这部分所占空间如果接近整个undo表空间的大小，就有风险。如果UNEXPIRED和EXPIRED占了大头，反而是好事，说明这些能被覆盖重用。undo表空间的扩展逻辑跟普通表空间一样，加数据文件即可。但要注意，undo表空间不宜盲目扩很大，因为UNDO_RETENTION参数控制的是undo保留时间，如果空间不够，Oracle会直接覆盖未过期的undo，导致ORA-01555快照过旧错误，这种错误在报表长查询场景特别常见。
2.4 高水位线问题：删除数据后空间却不释放
另一个高频问题：删了表里几百万行数据，但表空间使用率纹丝不动。这是因为Oracle的段（segment）存在高水位线（HWM），DELETE操作只是把数据标记为删除，并不会自动释放分配给段的块。要释放空间，常规手段是重组表：
sql复制SQL> alter table big_table enable row movement;
SQL> alter table big_table shrink space cascade;
shrink space可以在线执行，不需要停机，但前提是表所在表空间必须是开启自动段空间管理（ASSM），11g之后默认都是。执行shrink的时候会触发行移动，所以需要先enable row movement，否则报ORA-10631。另一个更硬核的方式是alter table big_table move，但这个操作会在表上锁，期间该表的DML会被阻塞，适合停机维护窗口做。
如果你的表是分区表，可以逐分区shrink或者move，控制影响范围。shrink之后记得重建索引，因为行移动会导致索引失效或者性能下降，这个坑我踩过一次，shrink完忘重建索引，第二天SQL慢得一批，一查才发现索引的聚簇因子已经烂了。
3. 用户、权限与安全配置：等保合规和日常授权都靠这些
安全这一块，早年很多Oracle库根本不管，DBA都拿system账号到处用，应用连库也是用sys或者system，这在等保测评里一查一个准。现在等保2.0对数据库的要求非常明确，口令策略、登录次数限制、权限分立都是硬指标。说白了，DBA如果不懂安全配置，等保测评过不去，严重的还会被通报。
3.1 用户创建与Profile口令策略
创建用户的语法不难，难的是按照安全基线来创建。等保要求密码复杂度、登录失败锁定、会话空闲超时，这些都得通过Profile来实现。
sql复制SQL> create profile app_user_profile limit
failed_login_attempts 5
password_lock_time 1
password_life_time 90
password_grace_time 7
password_reuse_time 180
idle_time 30;
failed_login_attempts 5表示连续5次密码错误锁定账号，password_lock_time 1锁定1天，password_life_time 90密码90天过期，password_grace_time 7过期后宽限7天，password_reuse_time 180表示180天内不能重复使用旧密码，idle_time 30是会话空闲30分钟自动断开。这些参数是等保测评里经常查的项目。
创建用户时可以带上默认表空间和临时表空间，千万别忽略，否则默认落到SYSTEM表空间，长期下来可能导致SYSTEM表空间膨胀，这个坑我见过多次：
sql复制SQL> create user app_user identified by "ComplexPwd_2024"
default tablespace users
temporary tablespace temp
profile app_user_profile
account unlock;
密码用双引号包起来可以避免特殊字符被SQL*Plus解析问题，但要注意密码里别带中文字符和单引号，否则后面麻烦。生产规范里，创建应用账号时一定不要直接给DBA角色，能不给dba就不给dba，这是底线。
3.2 最小权限授权：查询权限、对象权限、系统权限分开给
创建完用户之后，给权限就要讲究了。等保和Oracle最佳实践都强调最小权限原则。有的运维图省事，grant dba to app_user;一行完事，这在生产上是重大安全隐患。
给应用账号常用的是这几类授权：
sql复制SQL> grant connect, resource to app_user;
SQL> grant create session to app_user;
SQL> grant select, insert, update, delete on schema_name.table_name to app_user;
SQL> grant select on sys.dba_data_files to app_user;
connect和resource是Oracle预定义的角色，connect包含create session权限，够用；resource包含创建表、序列、存储过程等对象权限，适合开发库，生产环境建议按需给，不一定要resource。视图查询权限也很重要，如果应用要查数据字典视图，比如dba_data_files、v$session，需要显式授权，因为普通账号默认没有这些视图的查询权限。Oracle有select_catalog_role这个角色，给了它就能查大部分数据字典视图，但不是所有。
撤销权限用revoke，语法跟grant对称：
sql复制SQL> revoke select on schema_name.table_name from app_user;
3.3 角色与视图权限：一套可以减少反复授权的方案
如果表特别多，一张张grant太麻烦，可以用角色把权限打包。DBA最常用的做法是创建角色，把一堆表的权限授予角色，再把角色授予用户。这样后续新表加入时，只需给角色授权，所有拥有角色的用户自动获得权限。
sql复制SQL> create role read_only_role;
SQL> grant select on hr.employees to read_only_role;
SQL> grant read_only_role to app_user;
另外，很多团队会建一个只读账号给报表、BI查询用，这类账号最好只给create session加对具体表的select权限，不要给resource，更不要给dba。我在不少企业看到报表账号权限大得能删库，一问就是“当时图省事”。
3.4 审计命令：等保测评必查项
等保测评有一项必查的是数据库审计是否开启。Oracle的传统审计功能默认是关闭的，需要手动开启并设置参数。
sql复制SQL> show parameter audit_trail;
SQL> alter system set audit_trail=db,extended scope=spfile;
audit_trail有none（关闭）、db（开启审计，写入审计表）、db,extended（开启审计并记录SQL文本和绑定变量）、os（写入操作系统文件）、xml（写入XML文件）几种取值。db,extended是最常用的，因为能查到具体执行的SQL。注意这个参数是静态参数，改完需要重启数据库才生效。
审计开启之后，还要配置具体审计策略，比如登录审计、DDL审计：
sql复制SQL> audit create session by access;
SQL> audit create any table by access;
SQL> audit drop any table by access;
by access表示按访问次数记录审计，by session表示按会话记录，前者审计数据量更大但更精确，后者更省空间。生产环境建议只审计关键操作，别把所有表都审计一遍，否则审计表AUD$会以惊人的速度膨胀，最终把SYSTEM表空间塞满。我见过一个客户库里AUD$涨到几十个G，整个系统卡死，就是因为审计策略配得太狠。
查看审计记录：
sql复制SQL> select os_username, username, action_name, returncode, to_char(timestamp,'yyyy-mm-dd hh24:mi:ss') as login_time
from dba_audit_trail
where returncode != 0
order by timestamp desc;
returncode非0表示操作失败，比如密码错误、权限不足，这个在排查安全事件时特别有用，能直接看到谁在尝试爆破密码。注意dba_audit_trail这个视图很大，查询时一定要加条件和时间范围，否则全表扫描能把数据库拖垮。
4. 备份与恢复：数据安全的最后一道防线
备份恢复是DBA最核心的职责，没有之一。不夸张地说，一个DBA水平高低，看他写的备份脚本和恢复演练水平就能判断个大概。这里不讲太深入的RMAN恢复原理，只把最常用的备份命令和冷迁移实操捋清楚。
4.1 RMAN全备与增量备份的基本姿势
RMAN用起来其实不复杂，难在备份策略设计。我最推荐的方式是用backup database配合plus archivelog，一条命令完成数据文件和归档日志的备份，并自动删除已备份的归档日志，免得归档堆积撑爆磁盘。
bash复制rman target /
进入RMAN之后：
sql复制RMAN> configure controlfile autobackup on;
RMAN> backup database plus archivelog delete input format '/backup/orcl/full_%d_%T_%s_%p.bak';
%d是数据库名，%T是日期，%s是备份集编号，%p是片编号，这样备份文件名唯一且可读。delete input表示备份完成后删除源归档文件，这个必须加，否则归档目录会被撑爆。控制文件自动备份开启后，每次备份结束会自动备份当前控制文件和spfile，这相当于给恢复操作买了个保险。
增量备份策略，生产库一周一次0级增量，每天一次1级增量，是大多数企业的主流配置：
sql复制RMAN> backup incremental level 0 database plus archivelog delete input;
RMAN> backup incremental level 1 database plus archivelog delete input;
增量备份的好处是每天备份量小、速度快，恢复时先恢复0级再应用1级增量再叠加归档，RMAN会自动处理这个过程，不需要DBA手工一步步操作。
定时任务里，我习惯把RMAN命令写进shell脚本，然后用crontab调度，脚本里加一段日志和失败告警，这是生产环境的基本规范。脚本的核心就两段，一是调用rman执行备份，二是检查返回码，失败就发邮件告警。
bash复制#!/bin/bash
export ORACLE_HOME=/u01/app/oracle/product/19.0.0/dbhome_1
export ORACLE_SID=ORCL
export PATH=$ORACLE_HOME/bin:$PATH
LOG=/backup/logs/full_backup_$(date +%Y%m%d).log
rman target / log $LOG <<EOF
backup database plus archivelog delete input;
backup current controlfile;
EOF
if [ $? -eq 0 ]; then
echo "BACKUP SUCCESS: $(date)" >> /backup/logs/backup_history.log
else
echo "BACKUP FAILED: $(date)" >> /backup/logs/backup_history.log
fi
rman target /后面的log $LOG会把整条备份过程的输出写入日志文件，脚本结尾判断$?是RMAN进程的退出码，Linux命令成功返回0，非0就是失败。历史记录文件里存一行成功/失败标记，方便月度复盘和巡检抽查。
4.2 冷迁移：11g以及更老版本最可靠的搬迁方案
热词里有人搜“oracle 11g 数据库怎么冷迁移”，说明冷迁移这个场景并没有过时。为什么还有人要冷迁移？因为冷迁移是最简单、最不容易出错的方案，特别适合停机窗口充足、没有RMAN环境、跨不同主机迁移的场景。11g时代很多生产库没有配置完善的RMAN备份体系，直接用文件拷贝反而最稳。
冷迁移的核心步骤就是把数据库干净地关闭，把所有数据文件、控制文件、重做日志文件、spfile打包拷到新机器，然后在新机器上用同样的目录结构启动。具体操作：
先查询当前库所有文件的路径：
sql复制SQL> select name from v$datafile;
SQL> select member from v$logfile;
SQL> select name from v$controlfile;
SQL> show parameter spfile;
然后干净关闭数据库，这一步最关键，必须用shutdown immediate或者shutdown normal，千万别用shutdown abort冷拷贝，否则文件不一致，新库起不来。
sql复制SQL> shutdown immediate;
关闭之后直接用操作系统命令打包拷贝文件，注意要保留目录结构，权限也要对。
bash复制tar -czf /backup/orcl_cold_backup.tar.gz /u01/app/oracle/oradata/ORCL /u01/app/oracle/admin/ORCL/pfile
到新机器上解压，确保目录结构一致，然后设置环境变量，用sqlplus / as sysdba启动：
sql复制SQL> startup;
如果数据文件路径有变化，启动前先改控制文件里的路径，用alter database rename file，或者直接改pfile里的control_files和db_file_name_convert参数。冷迁移最大的坑就在这里——文件路径不一致导致控制文件找不到数据文件，报ORA-01157。解决方案有两个：一是保持路径完全一致（最简单），二是用db_file_name_convert参数做路径转换，或者用alter database rename file逐个改。
4.3 逻辑备份expdp/impdp：迁移部分数据时的正确选择
冷迁移适合整库搬迁，但如果你只需要迁移几张表或者某些schema的数据，用expdp/impdp更合适。逻辑备份导出的对象是逻辑数据，不限版本，11g导出来的可以用19c导入，这是它最大的优势。
导出整个schema：
bash复制expdp system/password@orcl schemas=hr directory=DATA_PUMP_DIR dumpfile=hr_full.dmp logfile=hr_full.log
directory=DATA_PUMP_DIR是数据库里的目录对象，指向操作系统实际路径。查这个路径用：
sql复制SQL> select directory_name, directory_path from dba_directories;
默认的DATA_PUMP_DIR指向$ORACLE_HOME/rdbms/log/，很多人不知道，导出的dmp文件跟日志文件混在一起难找。建议手动创建专用目录对象：
sql复制SQL> create directory dmp_dir as '/backup/dmp';
导入时注意目标库的目录对象是否已存在，导入前把目录建好，否则报ORA-39002。
导入：
bash复制impdp system/password@orcl directory=dmp_dir dumpfile=hr_full.dmp schemas=hr remap_schema=hr:hr_new
remap_schema可以把源schema映射到目标schema，在环境迁移、测试环境搭建时特别常用。remap_tablespace可以把表空间映射到目标库已有的表空间，避免导入报表空间不存在错误。有帖子搜到“oracle 19c impdp日志记录不完整”，这个遇到过一次，主要原因是导入过程中有对象报错，日志到报错点就断了，建议导入时加logfile参数，并在导入结束后检查日志文件的最后几行是不是Job "SYSTEM"."SYS_IMPORT_SCHEMA_01" successfully completed，看到这行才算成功。
5. SQL优化与执行计划：从“能跑”到“跑得快”的关键命令
很多开发同学找DBA帮忙，真正的问题不是数据库坏了，而是SQL跑得慢。DBA排查慢SQL有自己的套路，核心是抓住执行计划这个“七寸”。执行计划看不懂，优化无从谈起。
5.1 三步定位慢SQL
第一步，找到当前正在跑的慢SQL。Oracle里查正在执行的SQL最常用的视图是v$sql和v$session。
sql复制SQL> select sql_id, sql_text, elapsed_time/1000000 as elapsed_sec, cpu_time/1000000 as cpu_sec, buffer_gets, disk_reads, executions
from v$sql
where elapsed_time > 100000000
order by elapsed_time desc;
elapsed_time单位是微秒，除以1000000换算成秒。buffer_gets表示逻辑读次数，逻辑读高说明SQL在内存里大量扫描，通常会伴随高的disk_reads物理读。executions是执行次数，如果elapsed_time很大但executions小，说明单次执行就慢；如果两者都大，说明这条SQL频繁执行且每次都慢，对系统影响面更大。
第二步，生成执行计划。拿到sql_id之后，用dbms_xplan.display_cursor直接查看真实执行计划：
sql复制SQL> select * from table(dbms_xplan.display_cursor('sql_id', 0, 'ALLSTATS LAST'));
ALLSTATS LAST能显示实际执行行的行数和资源消耗，比默认的只显示计划更实用。如果看到某个步骤的A-Rows（实际返回行数）和E-Rows（预估行数）差了成百上千倍，说明统计信息不准或者优化器判断错误，这就是SQL慢的根源。
如果你是要优化一条还没跑的SQL，用explain plan for先看计划：
sql复制SQL> explain plan for select * from emp where deptno=10;
SQL> select * from table(dbms_xplan.display);
explain plan显示的是估算计划，不做实际执行，适合优化器评估阶段。但要注意，它不反映真实的资源消耗，只反映计划形状。
第三步，看统计信息是否新鲜。优化器做判断全靠统计信息，如果统计信息过期，执行计划就可能荒腔走板。
sql复制SQL> select table_name, last_analyzed from user_tables where table_name='EMP';
SQL> exec dbms_stats.gather_table_stats('HR','EMP', cascade=>true);
cascade=>true会同时收集表和索引的统计信息。统计信息对于大表来说收集时间是开销，一般生产环境用定时任务在业务低峰期执行。如果某张表数据量变化剧烈（比如每天insert几百万行），建议每天至少收集一次。
5.2 固定执行计划：让恶化的SQL“稳”下来
有时候一条SQL以前跑得飞快，最近突然变慢，排查半天发现是执行计划变了——优化器采用了错误的索引或连接顺序。这时候最快的解决方案是固定执行计划，让SQL始终采用那个正确的计划。
Oracle里的现代做法是SQL Plan Baseline，替代了老旧的outline（存储大纲）。用起来其实不复杂，三步就能完成：
sql复制SQL> alter session set optimizer_capture_sql_plan_baselines=true;
然后执行一次那个慢SQL，捕获到新计划，接着关闭捕获：
sql复制SQL> alter session set optimizer_capture_sql_plan_baselines=false;
查看已捕获的执行计划基线：
sql复制SQL> select sql_handle, plan_name, enabled, accepted from dba_sql_plan_baselines;
如果想把某个已接受的固定计划设为默认，用evolve或者手动加载。更直接的方案是通过dbms_sqlplan包或者create_outline，但baseline是官方推荐的方式，功能更强也更安全。实际上，每次Oracle升级或者参数调整后，总有一批SQL会“跑偏”，用baseline固定住关键SQL的计划，能避免很多线上性能事故。这个操作值得所有DBA学会。
5.3 常用SQL写法：connect by和not exists的高效使用
热搜词里出现了“oracle connect by start with”和“oracle not exists用法”，这两个是Oracle开发里的经典疑难。
connect by start with是层级查询，典型场景是组织机构树、BOM物料清单、菜单权限树。语法：
sql复制SQL> select empno, ename, mgr, level
from emp
start with mgr is null
connect by prior empno = mgr;
start with指定根节点，connect by prior empno = mgr表示当前行的empno等于下一行的mgr，level伪列表示层级深度。这里的关键记忆点是prior放在哪边，父子关系就往哪边连。如果数据成环，查询会死循环，Oracle有nocycle关键字可以用：
sql复制SQL> select empno, ename, mgr, level
from emp
start with mgr is null
connect by nocycle prior empno = mgr;
not exists的经典用法是查A表中有但B表中没有的记录。相比not in，not exists在子查询结果集较大时性能更好，且不会因为子查询里有NULL值而产生错误结果。not in遇到NULL值会返回空集，这是个著名的坑。
sql复制SQL> select * from employees e
where not exists (select 1 from department_archive d where e.dept_id = d.dept_id);
写not exists时有个习惯性细节：子查询里select 1就行，select *也行，优化器都会忽略列表达式，直接判断是否存在行。如果B表关联字段上有索引，not exists通常能利用上anti join（反连接）优化，性能远优于not in。
5.4 分页查询、trunc(sysdate)和dual表的几个实用细节
分页查询在Oracle 12c之前只有rownum，因为不支持limit，这是很多从MySQL转过来的开发最不习惯的地方。12c之后Oracle引入了fetch first子句，终于可以用类似MySQL的写法了：
sql复制SQL> select * from employees order by empno
fetch first 20 rows only;
如果要在12c之前模拟分页，标准写法是内联视图加rownum：
sql复制SQL> select * from (
select a.*, rownum rn from (
select * from employees order by empno
) a where rownum <= 40
) where rn > 20;
这里有个细节，最内层先排序，第二层用rownum <= 40限制最多取40行，最外层再过滤rn > 20，实现真正的20到40行。注意不要直接在最外层写rownum > 20，因为rownum是在行被查询出来的时候就分配的，rownum > 20永远不成立，这个坑我入行第一年就踩过。
trunc(sysdate)在热搜词里也出现了。它把日期类型的sysdate截断到当天零点，常用于日报、当日数据统计：
sql复制SQL> select count(*) from orders where create_time >= trunc(sysdate) and create_time < trunc(sysdate)+1;
这里要用>=和<构造一个半开区间，而不是用between加trunc(sysdate)和trunc(sysdate)+1，因为between是闭区间，会把第二天零点整的数据也算进来。trunc(sysdate)还可以配合'mm'、'yyyy'参数按月初、年初截断：
sql复制SQL> select trunc(sysdate, 'mm'), trunc(sysdate, 'yyyy') from dual;
dual表是Oracle的神奇存在，它就是个单行单列的虚拟表，任何不涉及具体表的查询都要从它上面绕一下。热搜词里有人问“dual最多存多大”，其实是个误解——dual本身不是存储表，它只是给select一个语法载体，它的“数据”不占用户空间，也不需要扩容。select 1 from dual;这种写法本质上就是告诉Oracle“给我执行这个表达式，返回一行结果”。
6. 几个被反复搜索的进阶场景与更稳妥的操作技巧
最后这部分来源于热搜和我在实际运维群里被问得最多的问题，单独拎出来说，因为它们各自有一定的独立性，但碰到一次就足以让人头疼一整天。包括ASM环境下的命令习惯、Oracle 12c删除不干净的问题、以及一些零散但非常实用的操作技巧。
6.1 ASM实例管理：别再用普通SQL思维操作磁盘组
装了RAC或者用了ASM存储的库，DBA要会登录ASM实例操作磁盘组。ASM实例没有数据文件，只有磁盘组。登录方式跟普通实例类似：
bash复制sqlplus / as sysasm
进入之后，查磁盘组状态：
sql复制SQL> select name, state, type, total_mb, free_mb from v$asm_diskgroup;
state是MOUNTED表示磁盘组已挂载，type是EXTERN（外部冗余）、NORMAL（两路镜像）或HIGH（三路镜像）。free_mb/total_mb算一下就知道空间余量。ASM磁盘组空间满了，往里面加磁盘即可，这个操作在线进行，不影响业务：
sql复制SQL> alter diskgroup DATA add disk '/dev/asm-disk5' name DATA_0005;
如果在Linux环境下，ASM磁盘的路径通常是/dev/oracleasm/disks/下的设备文件或者udev映射的/dev/asm-*设备。加盘前用lsblk或fdisk -l确认设备存在，别把系统盘加进去，那是灾难级的失误。
6.2 Oracle 12c及以后版本的“删除”问题：彻底干净地卸载和清理
有人搜“12c删除不干净+oracle”，这基本上是Windows环境下卸载Oracle之后，残留文件和服务导致重装失败的问题。Oracle的卸载确实远比普通软件麻烦得多，不只是卸载软件本身，还牵扯到目录、注册表、服务、环境变量、重启后残留进程。
正确的卸载流程是：先用Universal Installer删除Oracle主目录（通常是在C:\Oracle下运行deinstall.bat），它会自动清理大部分文件和服务。然后手动删除剩余目录，比如C:\app\用户名\product、C:\Program Files\Oracle。接着处理注册表，打开regedit，删除HKEY_LOCAL_MACHINE\SOFTWARE\ORACLE，这一步最容易漏，漏了重装时会报“指定的ORACLE_SID已存在”或者监听端口被占用。最后重启机器，确认没有OracleServiceORCL之类的服务残留。
Linux环境下删除12c，核心是执行$ORACLE_HOME/deinstall/deinstall，它会生成一个响应文件，自动删除数据库实例、监听、目录。之后手动删/etc/oratab里的记录，删/u01/app/oracle目录，然后清理/tmp下Oracle相关的临时文件。如果还装了Grid基础设施，那要更谨慎，先删数据库再删Grid，顺序反过来会搞得非常麻烦。
6.3 查询总金额、CLOB字段处理等实际工作中的高频写法规避
“oracle查询总金额”这种搜索词，通常是报表需求，比如要查订单总金额、销售总额。SQL其实很简单，无非是sum加group by：
sql复制SQL> select dept_id, sum(amount) as total_amt from orders group by dept_id;
报表SQL优化的关键在分析函数over()，比如同时显示每行的明细和总金额，普通group by做不到，得用窗口函数：
sql复制SQL> select dept_id, amount, sum(amount) over (partition by dept_id) as dept_total
from orders;
over(partition by …)会为每个分组计算累计值，同时保留每行明细，报表场景万金油。
CLOB字段的处理也是高频问题。CLOB最大支持4G，但SQL*Plus下直接用select查询只能显示前几百个字符，操作受限。常用方法是转成VARCHAR2后查询：
sql复制SQL> select dbms_lob.substr(content, 4000, 1) from articles where id=100;
dbms_lob.substr三个参数分别是CLOB字段名、截取长度、起始位置。如果要在PL/SQL里处理CLOB，用dbms_lob.read或dbms_lob.write更合适，因为substr有4000字符的限制。
6.4 查询Oracle版本和补丁信息：补丁管理的第一步
DBA在升级或者排查问题时，得先确认当前版本和补丁级别。版本查一次记不住没关系，关键是要知道命令在哪：
sql复制SQL> select banner from v$version;
SQL> select version, full_version from v$instance;
19c的full_version会显示包含补丁集的完整版本号，比如19.0.0.0.0加bundle编号。查已安装的补丁用opatch lsinventory命令：
bash复制$ORACLE_HOME/OPatch/opatch lsinventory
如果装了最新的补丁，opatch lsinventory会列出补丁ID和描述。补丁管理这块我多说一句，生产库尽量保持在官方支持的补丁级别，不要长时间不打补丁，不然出了问题，Oracle支持会让你先打补丁再排查，既费时间又被动。
7. 一个容易被忽视但极其重要的习惯：把常用命令做成自己的巡检手册
我整理了这么多命令，核心目的不是让你背下来，而是希望你能建立一套自己的巡检框架。命令是死的，场景是活的，只有理解每条命令解决什么问题、在什么场景下用，才真正算掌握。我自己的习惯是把常用命令按“实例状态、表空间、会话性能、备份恢复、安全审计”五个维度组织成一个Markdown文档，每次巡检照着过一遍，遇到问题也能快速定位到该敲哪条命令。
最后分享一个实操中总结的小经验：很多DBA处理故障时喜欢一条命令一条命令地试，试到哪算哪。我建议反过来，先花30秒把故障现象想清楚，“连不上”“慢”“报错”是不同的排查路径，对应的第一条命令完全不同。比如“连不上”先查监听和网络，“慢”先查等待事件，“报错”先查alert日志。带着明确的排查路径去敲命令，效率比瞎试高出好几倍，这也是老DBA和新手最明显的区别之一。希望这篇东西能帮你在面对Oracle时少走点弯路，真正把命令用成顺手工具而不是背不下来的负担。