Oracle运维必备：常用SQL整理与实战避坑指南

做Oracle运维这些年，我电脑里积累最多的其实不是架构图，而是一份随手记的SQL笔记。Oracle 常用运维SQL整理、改字段类型、改表名、创建基础用户并授权，这些操作几乎每次接手新库、处理变更工单或者应付安全检查时都会翻出来用。很多刚入行的同事总觉得Oracle运维很高深，动不动就上工具、开图形界面，实际上日常百分之七八十的工作，几条SQL就能搞定。这篇文章把我这些年沉淀下来的常用运维SQL做了一个系统梳理，覆盖对象结构变更、用户权限管理、高频查询、慢SQL优化与常见故障排查，尽量做到拿来就能用，每一段后面也补上了我踩过的坑和为什么要这么写的底层逻辑。

1. 这篇SQL整理解决什么问题

1.1 运维场景里最常被问到的SQL需求

我在实际工作中发现，Oracle运维里被问得最多的问题翻来覆去就那么几类：某张表的字段长度不够要扩容、表名命名不规范要改掉、新同事入职需要建一个只读账号、某个库的密码过期导致应用连不上。这些问题全部可以通过SQL在几分钟内解决，但前提是你得知道正确的写法和执行顺序。如果顺序错了，比如先改字段类型再处理依赖它的视图，或者授权前没把默认表空间安排妥当，后面就会冒出一连串幺蛾子。

1.2 常见的操作认知误区

先说一个最常见的误区：很多人以为改字段类型就是把ALTER TABLE ... MODIFY的语句一写就完事。实际上Oracle在底层对字段类型的转换有严格限制，不是所有类型都允许原地修改。比如VARCHAR2改成CLOB可以直接MODIFY，但NUMBER改成VARCHAR2就需要额外处理。如果不理解这个限制背后的原理，生产环境执行到一半报错，要回滚就非常被动。所以这篇笔记我特意把“为什么能改”“为什么不能改”“不能改时怎么办”这类底层逻辑也一并讲清楚，而不只是贴一条语句。

注意：下面的所有SQL我都基于Oracle 11g和19c两个版本来验证过。不同小版本在语法上会有细微差别，比如分页查询的OFFSET FETCH写法就要求12c以上才支持，文章中会特别标注版本要求。

2. 基础对象操作：改表名、改字段类型与字段改名

2.1 改表名的正确姿势与依赖处理

改表名在业务侧看只是一条语句的事，但运维侧必须先把依赖关系盘清楚。Oracle里改表名有两种写法：

sql复制-- 写法一：经典写法
RENAME old_table TO new_table;

-- 写法二：ALTER TABLE写法（官方更推荐）
ALTER TABLE old_table RENAME TO new_table;

两条语句在功能上相同，但要注意：RENAME是Oracle早期的命令，ALTER TABLE RENAME TO是标准写法。我习惯用第二种，因为它在DDL日志和权限控制上更统一。

改表名真正麻烦的是依赖对象。表上的索引、约束、触发器、同义词会跟着自动改名，这个Oracle处理得比较好，但视图、存储过程、函数、包内部的引用不会自动更新。这些对象编译后会变成失效状态（INVALID）。所以在执行修改之前，我通常会先查一下有多少对象引用了这张表：

sql复制SELECT owner, object_name, object_type, status
FROM dba_objects
WHERE status = 'INVALID'
  AND owner = 'APP_USER'
ORDER BY object_type, object_name;

如果发现视图或存储过程失效，就重新编译一次：

sql复制ALTER VIEW view_name COMPILE;
ALTER PROCEDURE proc_name COMPILE;

这里有个运维心得：在变更窗口里，我会提前用ALL_DEPENDENCIES视图把引用链拉出来，而不是等改完了再查失效对象。提前把依赖对象清单列出来发给业务方确认，比改完再补救要稳妥得多。

2.2 改字段类型：能改的直接改，不能改的走过渡方案

字段类型修改是日常运维里最考验功力的操作。先看最常见的场景：VARCHAR2长度不够，需要从50扩到200。

sql复制ALTER TABLE employees MODIFY (emp_name VARCHAR2(200));

这个操作在数据量小的时候秒级完成，但表里如果有几千万行，即使只是扩长度也可能需要较长时间，因为Oracle要扫描数据块做校验。生产环境大表修改，我一般放在夜间窗口，并且提前评估影响。另一个常见操作是VARCHAR2改成CLOB，Oracle允许这种原地转换：

sql复制ALTER TABLE employees MODIFY (emp_name CLOB);

注意，实际执行时Oracle会在内部做数据迁移，如果表很大，会消耗大量UNDO和临时表空间，务必提前确认临时表空间剩余量。

注意：NUMBER改成VARCHAR2、VARCHAR2改成NUMBER这类跨数据类型修改，Oracle直接执行会报ORA-01439: column to be modified must be empty to change datatype。原因很直接：Oracle无法保证原有数据在新类型下仍然合法，比如字符串里混入字母，转数字必然失败。所以Oracle规定这类修改只允许在空列上进行。

那非空列要跨类型怎么办？我推荐用过渡列方案，这是我在生产环境里用过最稳的一种：

sql复制-- 第一步：新增临时列
ALTER TABLE employees ADD (emp_name_temp VARCHAR2(50));

-- 第二步：把原列数据拷贝到临时列
UPDATE employees SET emp_name_temp = TO_CHAR(emp_name);
COMMIT;

-- 第三步：把原列置空
ALTER TABLE employees MODIFY (emp_name NULL);
UPDATE employees SET emp_name = NULL;
COMMIT;

-- 第四步：修改原列类型
ALTER TABLE employees MODIFY (emp_name VARCHAR2(50));

-- 第五步：把临时列数据拷回原列，然后删除临时列
UPDATE employees SET emp_name = emp_name_temp;
COMMIT;
ALTER TABLE employees DROP COLUMN emp_name_temp;

这套方案看起来多几步，但每一步都可控，中途任何一步出问题都可以安全回退。如果表非常大，第二步和第五步的UPDATE会锁表，建议分批次执行，比如加个WHERE条件按主键范围分片更新，避免阻塞业务。还有一种备选方案是把数据导出、重建表、再导入，但那是停机方案，对在线业务不友好。

2.3 改字段名与默认值、非空约束的处理

字段改名相对简单，Oracle 9i之后支持：

sql复制ALTER TABLE employees RENAME COLUMN emp_name TO employee_name;

改字段名同样要注意视图、存储过程和触发器这些依赖对象。很多人忽略了字段默认值的问题。如果列上有DEFAULT，改名后默认值会保留，不用额外处理。但如果你同时想改默认值，需要单独执行：

sql复制ALTER TABLE employees MODIFY (employee_name DEFAULT '未知');

另一个高发问题是非空约束。如果一个字段原来允许为空，你想改成NOT NULL，直接MODIFY会报ORA-01407: cannot update ... to NULL，说明表里已经有NULL数据了。处理方式有两种：先补全NULL数据再修改，或者直接给默认值：

sql复制-- 如果存量数据可以统一补值
UPDATE employees SET employee_name = '未知' WHERE employee_name IS NULL;
COMMIT;
ALTER TABLE employees MODIFY (employee_name NOT NULL);

运维过程中我养成了一个习惯：每次执行结构变更前，先跑一遍数据探查，看看目标列有没有NULL、有没有超长数据、有没有重复值。这几个问题不提前发现，执行时多半会失败。

3. 用户与权限管理：创建基础用户并授权

3.1 一套可以直接拿来用的建号授权脚本

创建用户并授权是Oracle运维里最基础也最容易出错的环节。很多事故不是语句写错，而是权限给得太大或者太小。下面是我实际用的标准模板，适用于大多数业务系统的新建账号场景：

sql复制-- 第一步：创建用户
CREATE USER app_read IDENTIFIED BY "YourStrongPass123"
DEFAULT TABLESPACE users
QUOTA 10M ON users
TEMPORARY TABLESPACE temp
PROFILE app_profile;

-- 第二步：赋予基础权限
GRANT CONNECT TO app_read;

-- 第三步：赋予对象权限（只读场景）
GRANT SELECT ON schema_name.table_a TO app_read;
GRANT SELECT ON schema_name.table_b TO app_read;

如果是要给业务应用一个读写账号，通常还需要：

sql复制GRANT CREATE SESSION TO app_rw;
GRANT SELECT, INSERT, UPDATE, DELETE ON schema_name.table_a TO app_rw;

这里有个非常容易踩的坑：Oracle的授权语句里，对象名和用户名最好不要加引号。如果建用户时用了双引号小写用户名，比如CREATE USER "app_read"，那么之后每次登录和授权都必须精确匹配大小写，否则提示ORA-01918: user 'APP_READ' does not exist。我见过不止一次因为这个问题把生产账号搞挂的，所以建议一律用大写不带引号的方式创建。

3.2 权限层级和角色背后的逻辑

要搞清楚授权，必须先理解Oracle权限的三层结构：系统权限、对象权限和角色。

系统权限是操作数据库级别的能力，比如CREATE SESSION（登录）、CREATE TABLE（建表）、CREATE PROCEDURE（建存储过程）。对象权限是针对具体对象的操作权，比如对某张表的SELECT、INSERT。角色是一组权限的集合，方便批量管理。比较常用的是CONNECT和RESOURCE这两个角色。CONNECT角色在旧版本基本上就是CREATE SESSION，但在新版本里角色定义已经变了，不再包含其他权限；RESOURCE角色以前包含CREATE TABLE、CREATE SEQUENCE等，但在12c之后Oracle官方已经不再推荐给业务用户授予RESOURCE角色。

所以现在建业务账号，我的经验是最小化授权：只给CONNECT，再按需给具体对象权限。不要图省事一把GRANT ALL，这种习惯在生产环境迟早出事。曾经有个开发同学拿着一个权限过大的账号做联调，误操作把一张配置表清空了，教训很深刻。

3.3 密码策略与关闭密码有效期

Oracle 11g之后默认开启了密码有效期限制，默认180天。很多应用突然连不上数据库，十有八九是密码过期了。查询密码是否过期：

sql复制SELECT username, account_status, expiry_date
FROM dba_users
WHERE username = 'APP_USER';

如果账号状态显示EXPIRED或EXPIRED(GRACE)，需要重置密码并解锁：

sql复制ALTER USER app_user IDENTIFIED BY "NewPass123" ACCOUNT UNLOCK;

如果测试环境不想被180天密码策略折磨，可以把密码生命周期设为无限：

sql复制ALTER PROFILE app_profile LIMIT PASSWORD_LIFE_TIME UNLIMITED;

但这个操作在生产环境要谨慎，等保审计一般会要求密码定期更换，改成UNLIMITED可能过不了合规检查。所以这篇文章的标题虽然叫“常用运维SQL整理”，但每一条SQL背后都有取舍，建议读者根据自己环境的合规要求来判断。顺便提一句，如果公司安全规范要求等保整改，那么查询账号状态、权限清单这一类的SQL要多准备几个，后面第6章我会一并整理。

4. 日常运维高频查询SQL清单

4.1 分页查询：两种写法和一个性能大坑

Oracle的分页查询可以说是最常被搜索的SQL需求。旧版经典的ROWNUM写法：

sql复制SELECT *
FROM (
  SELECT t.*, ROWNUM rn
  FROM (SELECT * FROM employees ORDER BY emp_id DESC) t
  WHERE ROWNUM <= 20
)
WHERE rn >= 11;

这段SQL的逻辑是先按条件排序，再用ROWNUM过滤出前20行，最后在外层丢弃前10行。注意内层ROWNUM的条件必须写成<=，不能写成BETWEEN 11 AND 20，因为ROWNUM是在行被取出的过程中逐行分配的，如果一开始就要求ROWNUM大于某个值，结果集会为空。

12c之后Oracle引入了标准的OFFSET FETCH分页写法，写法直观很多，性能也更好：

sql复制SELECT * FROM employees
ORDER BY emp_id DESC
OFFSET 10 ROWS FETCH NEXT 10 ROWS ONLY;

这里要提醒一个性能大坑：深分页场景下OFFSET值越大，数据库需要扫描并丢弃的行越多，会越来越慢。如果业务有海量数据分页需求，建议改用键集分页（Keyset Pagination），用上一页最后一条记录的ID作为下一页的起点，而不是用页数偏移。

4.2 日期处理与trunc(sysdate)的高频用法

Oracle里日期处理是日常查询的重头戏，trunc(sysdate)这个函数我几乎每天都在用。它的作用是把日期截断到指定精度，最常用的是截到天：

sql复制-- 今天的0点
SELECT TRUNC(SYSDATE) FROM dual;

-- 本月第一天的0点
SELECT TRUNC(SYSDATE, 'MM') FROM dual;

-- 本年度第一天的0点
SELECT TRUNC(SYSDATE, 'YYYY') FROM dual;

实际运维里这些写法经常用于统计和清理任务。比如查某张表今天新增的数据量：

sql复制SELECT COUNT(*) FROM orders
WHERE create_time >= TRUNC(SYSDATE)
  AND create_time < TRUNC(SYSDATE) + 1;

这里用大于等于当天零点、小于第二天零点的写法，是为了避免忽略create_time带时分秒时用等于号漏数据。另一个高频场景是查最近7天数据，可以直接：

sql复制SELECT * FROM orders
WHERE create_time >= TRUNC(SYSDATE) - 7;

这里有一个和索引相关的坑：在create_time上建了索引，但如果查询条件写成TRUNC(create_time) = TRUNC(SYSDATE)，函数套在列上会导致索引失效，全表扫描。正确的做法是把条件右侧写成区间，让列保持原样，索引才能走得上。

4.3 树形查询：connect by start with

Oracle的树形查询是其他数据库羡慕很久的功能。查组织架构、菜单树、BOM清单这类场景非常顺手。基本语法：

sql复制SELECT emp_id, emp_name, manager_id, level
FROM employees
START WITH manager_id IS NULL
CONNECT BY PRIOR emp_id = manager_id;

这段SQL的含义是：从manager_id为空的顶级节点开始，按照“上一行的emp_id等于下一行的manager_id”规则向下展开。LEVEL伪列表示当前行在树中的深度。如果想把层级拼接成缩进效果，可以配合LPAD：

sql复制SELECT LPAD(' ', (LEVEL - 1) * 2, ' ') || emp_name AS emp_tree
FROM employees
START WITH manager_id IS NULL
CONNECT BY PRIOR emp_id = manager_id;

使用CONNECT BY时有几个细节要注意：如果数据里有循环引用，比如A的上级是B，B的上级又是A，查询会报ORA-01436: CONNECT BY loop in user data。遇到这种情况可以用NOCYCLE关键字跳过循环：

sql复制SELECT emp_id, emp_name, manager_id
FROM employees
START WITH manager_id IS NULL
CONNECT BY NOCYCLE PRIOR emp_id = manager_id;

树形查询的另一个变体是从子节点往上递归找所有祖先，把PRIOR放到等号另一侧即可。这个技巧在处理权限层级时非常实用。

4.4 集合过滤：not exists、distinct与一条SQL的取舍

很多同事写去重第一时间想到SELECT DISTINCT，但用之前要想清楚：DISTINCT是把结果集里完全重复的行合并，如果只想去重某一列而其他列不同，DISTINCT是解决不了的。常见场景是查“这个月有订单的客户列表”，写DISTINCT可以：

sql复制SELECT DISTINCT customer_id
FROM orders
WHERE order_date >= TRUNC(SYSDATE, 'MM');

但如果需求变成了“查有订单且订单金额大于1000的客户信息”，还关联了客户主数据表，这时候用EXISTS或NOT EXISTS才是更清晰且性能更稳的选择。

NOT EXISTS的经典用法是查“没有下过订单的客户”：

sql复制SELECT customer_id, customer_name
FROM customers c
WHERE NOT EXISTS (
  SELECT 1
  FROM orders o
  WHERE o.customer_id = c.customer_id
    AND o.order_date >= TRUNC(SYSDATE, 'MM')
);

NOT EXISTS的性能通常优于NOT IN，原因在于NOT IN遇到子查询结果中有NULL时会直接不返回任何行，逻辑上容易踩坑；NOT EXISTS则不存在这个问题。如果你一定要用NOT IN，得确保子查询列没有NULL。另外，两张表关联去重时，很多人喜欢用JOIN，但JOIN会把一对多关系放大，导致结果行数变多，这时候改成EXISTS反而更符合业务表达。

4.5 字符串处理：取最后一个字符、判断字母类型

字符串处理在运维SQL里也经常出现，比如从编码字段里截取末位、判断一个字段是否全字母。获取字符串最后一个字符最直观的写法是结合SUBSTR和LENGTH：

sql复制SELECT SUBSTR(employee_code, LENGTH(employee_code)) FROM employees;

如果想取倒数第2个字符，把第二个参数改成LENGTH(employee_code) - 1即可。判断一个字符串是否全是字母，正则是最省事的方式：

sql复制SELECT employee_name,
       CASE WHEN REGEXP_LIKE(employee_name, '^[A-Za-z]+$') THEN '纯字母' ELSE '含其他字符' END
FROM employees;

REGEXP_LIKE是Oracle正则表达式家族里最常用的函数，常和REGEXP_REPLACE、REGEXP_SUBSTR配套使用。查询字段里是否出现数字可以用：

sql复制SELECT employee_name
FROM employees
WHERE REGEXP_LIKE(employee_name, '[0-9]');

这里提醒一句：在WHERE条件里对字段用正则做过滤，通常无法走普通索引，数据量大时会很慢。如果这个需求频繁出现，建议增加一个冗余字段或使用函数索引。

4.6 dual表与其他高频查询

Oracle里有一个独特的dual表，它只有一个叫DUMMY的字段，专门用于SELECT不带表名的表达式。比如：

sql复制SELECT SYSDATE, USER, 1 + 1 FROM dual;

很多新人会疑惑dual表是干什么的，其实它就是Oracle为了方便计算常量而提供的虚拟表。dual最多能存多大？这个问题没有实际意义，因为dual表本身由数据库管理，用户无法写入数据，它的结构和大小由系统维护。

日常运维中还经常需要查表空间使用率、会话状态和最近执行的慢SQL。这些查询SQL虽然不属于“改字段类型”这类结构变更，但同样是运维高频：

sql复制-- 查表空间使用率
SELECT df.tablespace_name,
       ROUND(df.total_size / 1024 / 1024, 2) AS total_mb,
       ROUND((df.total_size - fs.free_size) / 1024 / 1024, 2) AS used_mb,
       ROUND(fs.free_size / 1024 / 1024, 2) AS free_mb
FROM (SELECT tablespace_name, SUM(bytes) total_size
      FROM dba_data_files GROUP BY tablespace_name) df,
     (SELECT tablespace_name, SUM(bytes) free_size
      FROM dba_free_space GROUP BY tablespace_name) fs
WHERE df.tablespace_name = fs.tablespace_name;

这些SQL不复杂，但每次磁盘告警、表空间不够时的排查都靠它们。我建议把这些查询做成一个只读账号下的视图或固定脚本，需要时直接执行，省得现场拼SQL。

5. 慢查询与优化：从执行计划看起

5.1 一条SQL为什么会慢：查看执行计划

同样的SQL，跑到不同库上性能可能天差地别。运维排查慢SQL，第一步通常不是改SQL，而是看执行计划。Oracle里最简单的方式：

sql复制EXPLAIN PLAN FOR
SELECT * FROM orders WHERE customer_id = 100;

SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);

如果SQL已经在跑了，也可以从共享池里找到它的SQL_ID，再查实际执行计划：

sql复制SELECT sql_id, sql_text, elapsed_time, executions
FROM v$sql
WHERE sql_text LIKE '%orders%'
ORDER BY elapsed_time DESC;

拿到SQL_ID后：

sql复制SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_CURSOR('sql_id_这里替换', NULL, 'ALLSTATS LAST'));

从执行计划里重点看操作类型：是TABLE ACCESS FULL（全表扫描）还是INDEX RANGE SCAN（索引范围扫描）。如果大表出现了全表扫描，并且过滤条件的选择性很好，大概率是索引缺失或者写法导致索引失效。

5.2 优化SQL的几个基础原则

根据我处理过的慢SQL案例，绝大部分性能问题都可以归结为几个原因：

第一，WHERE条件里对索引列做了函数运算，比如TRUNC(create_time) = TRUNC(SYSDATE)，这会导致索引失效。第二，使用了SELECT *，把不需要的大字段也查出来，增加了I/O。第三，多表关联时驱动表选择不当，导致中间结果集过大。第四，分页查询的OFFSET过大，深翻页越来越慢。

针对这些原因，常规优化手段也很明确：函数运算移到右侧、只查需要的列、用EXISTS替代IN、合理设计联合索引。比如联合索引的字段顺序一般把等值条件的列放前面，范围条件的列放后面，这样能最大化索引利用率。

5.3 固定执行计划的思路与工具

还有一个进阶场景：有些SQL在测试环境跑得好好的，上了生产就因为统计信息偏差走了错误的执行计划。这种情况下，DBA通常会考虑固定执行计划。传统的方式有两种：SQL Profile和SQL Plan Management（SPM）。

SPM的思路是把一个SQL的好执行计划“捕获”并固定下来，之后优化器即使因为统计信息变化想换计划，也会先和SPM里保存的计划做比较，只有新计划成本明显更优才会使用，并且新计划需要验证之后才能启用。这个机制生产环境很实用。启用SPM需要先设置：

sql复制ALTER SYSTEM SET optimizer_capture_sql_plan_baselines = TRUE;

然后让目标SQL跑一遍，抓取执行计划，再用DBMS_SPM包管理。不过要注意，SPM本身是个不小的主题，线上开启前要先在测试环境做充分验证，避免因为基线管理策略不当导致执行计划被锁定在不优状态。

我个人运维时更常用的辅助工具是给查询频繁、逻辑稳定的SQL加上提示（Hint），比如：

sql复制SELECT /*+ INDEX(employees idx_emp_name) */ employee_name
FROM employees
WHERE employee_name = '张三';

但Hint是一把双刃剑，如果索引被删除或改名，带Hint的SQL会直接报错。所以Hint只应该作为短期止血手段，长期还是要把统计信息刷准，让优化器自己选对路：

sql复制BEGIN
  DBMS_STATS.GATHER_TABLE_STATS('APP_USER', 'EMPLOYEES', CASCADE => TRUE);
END;

统计信息不准是很多“莫名变慢”问题的根源，刷新统计信息后性能自动恢复的情况我遇到过太多次了。

6. 常见问题与排查实录

6.1 运维常见错误速查表

下面把我在工作中遇到频率最高的Oracle运维错误整理成一张速查表，方便大家遇到问题时快速定位。

这张表里ORA-01439和ORA-28000这两类是我遇到过最多的，也是很多新人在线上一慌就乱操作的场景。遇到报错先不要急着重跑，先读一下错误信息里的详细位置，大部分时候问题都出在数据本身，而不是SQL语法。

6.2 授权后依然提示无权限的排查思路

有一个特别折磨人的场景：给用户授权了，用户重新登录后依然提示ORA-00942或ORA-01031。我排查类似问题时的顺序通常是：

先确认是不是授权给了错误的schema。SELECT权限必须由对象所在的schema用户执行，或者由DBA角色用户执行，例如APP_USER下的表，要确认是GRANT SELECT ON app_user.table_a TO app_read，而不是其他用户下的同名表。

再检查用户登录后使用的schema。如果用户连接串里没有指定schema，Oracle会默认使用用户名作为schema。此时表虽然被授权了，但SELECT语句里如果写了table_a而不是app_user.table_a，解析时会在当前schema下找不到表。

最后检查角色权限是否生效。某些权限通过角色授予后，在存储过程里默认不生效，Oracle的PL/SQL默认不会激活角色权限。如果存储过程需要访问其他schema的表，要直接把对象权限授予执行存储过程的用户，而不是通过角色间接授权。

6.3 数据库迁移与冷备份的两个小提醒

虽然这篇文章主要讲运维SQL，但很多读者搜索时会带上冷迁移、恢复Oracle这类词，我也顺带提一些SQL之外的心得。Oracle冷迁移通常需要把数据文件、控制文件、参数文件等整体拷贝到新机器上，关键是要保持文件路径一致，或者修改spfile里的路径参数。做这类操作前，一定要把数据库干净地关闭，确认没有未完成的日志归档，否则启动时会报一致性错误。

还有一点容易被忽略：归档日志的连续性。如果你要做基于文件拷贝的恢复，归档日志缺了一个都起不来。建议用RMAN做备份而不是简单COPY文件，RMAN会自动校验文件一致性。这条建议来自我早年间吃过的一次亏：以为文件拷贝全了，结果启动时差了最后一个归档日志，折腾了一整天才恢复。

6.4 最后分享一个我自己的运维小习惯

我在处理这些结构变更时，习惯把每一步SQL都记录在一个变更脚本里，并在执行前先跑一遍TABLESPACE剩余空间查询、索引状态查询、依赖对象查询。哪怕只是一个简单的字段扩容，我也会先看看这个表是不是有同步任务在跑、有没有长事务锁住。等到执行时再用一个只读事务的方式先跑EXPLAIN PLAN，确认影响行数。

这个习惯帮我避免过很多次生产事故。有一次我准备改一张订单表的字段类型，同事说“直接改就行”，我坚持先查了一下依赖，发现有个物化视图引用了这个列。如果强行改，物化视图会变成失效状态，而刷新任务会直接报错。提前发现后，我把物化视图的重建步骤也一并写进了变更方案，整个过程无感切换。做运维SQL整理也一样，重要的不是背下多少条SQL，而是知道每一条SQL执行前应该确认哪些前置条件、执行后会产生哪些影响。这套思路建立起来，无论以后遇到什么数据库，都能稳稳接住。