企业官网建设流程全解析

1. 先把这套“三件套”的关系捋清楚

1.1 表空间、用户、权限到底各自管什么

刚接手一套新库的时候，我见过太多人把这段脚本抄来就改个名字直接跑，结果表建出来了，数据也能写进去，等到几个月后磁盘被打满，才发现当初某个数据文件写了 MAXSIZE UNLIMITED。表空间、用户、授权这三件事在 Oracle 里几乎是绑定出现的，但它们负责的层面完全不同，混在一起想就容易出事。

用仓库打个比方就很好理解：表空间是物理仓库的实际仓位，它对应磁盘上一个或多个数据文件，决定数据真正落在哪块盘上、能长多大、涨多快；用户是一个带工牌的账户，它需要指定自己默认在哪个仓库干活（默认表空间）、临时堆放物料用什么场地（临时表空间）、最多能占多少仓位（配额）；授权则是门禁卡的权限范围，决定这个账户能不能进门（CREATE SESSION）、能不能自己开新货架（CREATE TABLE）、能不能读别人仓库里的东西（对象权限）。

三者串起来是一条完整链路：先有空间，再有人，最后给权限。顺序颠倒也能执行，但会留下一堆半成品，比如用户建好了却没默认表空间，Oracle 会把他丢到数据库级默认的 USERS 里，几十个业务账号全挤在一个表空间上，后期想分离都难。

我个人的习惯是，新上一个业务模块，第一件事不是建表，而是把“这个模块的数据量级、增长速度、是否需要独立备份恢复”这三个问题问清楚，答案直接决定了表空间怎么规划。数据量估算错了可以扩，架构上把不该混的混在一起，后面拆起来就是一场硬仗。

1.2 为什么不能图省事全塞进 USERS

新手最常问的一句话是“我直接建个用户，表空间用默认的，行不行”。技术上当然行，但在实际项目里这是隐患。默认表空间如果统一是 USERS，所有业务的数据文件混在一起，容量管理就完全失控：你无法单独知道哪个模块占了多少空间，更没法针对某个模块做表空间级的迁移或独立备份。

举个我踩过的坑。早年间一个报表模块和交易主库共用同一个表空间，报表那边动不动就跑一个全表扫描生成大临时结果集，把数据文件顶到 MAXSIZE，交易侧插入直接报ORA-01653。当时排查花了大半天，因为从应用报错根本看不出是报表那边把空间吃掉的。后来把报表拆到独立表空间，配了独立的配额上限，问题再没复现过。

所以我的原则很朴素：按业务模块或按数据生命周期划分表空间，热数据和冷数据分开，日志表和主数据分开，需要单独做只读或归档的单独放。这跟文件系统里按目录分账是一个思路，管理成本换来的是可控性。

1.3 本次演示的完整目标

为了把流程讲透，我按一次真实交付的路径走一遍：假设要给一个新的业务模块建一套独立的存储和账号，要求是——独立的永久表空间、配套的临时表空间、一个专属业务用户、按最小权限原则授权、最后跑一遍验证脚本确认一切正常。

中间会涉及参数怎么算、路径怎么选、自动扩展怎么设、授权授到什么程度、出问题怎么查。每一步我都会说清楚“为什么这么定”，而不是只给一段能跑的 SQL。因为脚本抄错一个数字，可能要等到半年后磁盘告警才会暴露。

注意：下面的所有对象名、路径都是示例值，实际执行前必须替换成你自己的命名规范和存储路径。

2. 动手前必须确认的四件事

2.1 确认实例状态和当前连接身份

很多人上来就执行 CREATE TABLESPACE 报ORA-01031: 权限不足，原因是连错了账户。建表空间、建用户这类操作需要SYSDBA或至少具备CREATE TABLESPACE、CREATE USER系统权限的账号。先确认自己在哪：

-- 查看当前会话身份 SHOW USER; -- 查看实例基本信息 SELECT instance_name, status, database_status, log_mode FROM v$instance; -- 确认自己在 CDB 还是 PDB（12c 及以上） SHOW CON_NAME;

如果你用的是多租户架构，业务用户和数据文件通常要建在PDB里。在 CDB$ROOT 下执行建用户，建出来的是公共用户，后面应用连上来会找不到对象。切容器这一步别偷懒：

ALTER SESSION SET CONTAINER = pdb_name;

我见过最冤的一次事故是，脚本在 CDB 里跑完，日志一切正常，应用连上 PDB 报“用户不存在”。查了半天才发现是会话没切。所以现在我的习惯是，脚本第一行就写ALTER SESSION SET CONTAINER = xxx;，让执行环境自带说明。

2.2 存储路径和剩余空间先看再建

数据文件路径不是随便写的，必须满足两个条件：目录已存在，且Oracle 的操作系统账户对该目录有写权限。Oracle 不会帮你创建目录，路径不存在直接报ORA-01119。

登录主机侧确认一遍：

# 查看目标挂载点的剩余空间 df -h /u01/app/oracle/oradata # 确认目录归属 ls -ld /u01/app/oracle/oradata/ORCL

估算空间的时候留足余量。我的经验值是：初始数据文件大小按首年预估数据量的 1.5 倍起，磁盘可用空间至少留出 30% 的缓冲。因为自动扩展一旦开启，涨起来是很快的，而磁盘写满之后影响的不只是这一个库，同机器上的其他实例也会跟着遭殃。

另外还要看一眼db_files参数。它是整个数据库允许的数据文件总数上限，小文件表空间加数据文件是在消耗这个额度：

SHOW PARAMETER db_files; SELECT COUNT(*) FROM dba_data_files;

如果已经接近上限，优先考虑用BIGFILE 表空间，一个 BIGFILE 只算一个文件，能突破小文件表空间的单文件大小限制，管理上也省心。

2.3 命名规范：别用双引号，别用中文

命名这件事看起来是小事，实际上是后期运维成本的大头。我的建议固定成几条：全部大写英文加下划线、以业务模块前缀开头、按用途加后缀区分类型。比如CRM_DATA是业务数据、CRM_TEMP是临时、CRM_IDX是索引。

为什么强调大写？因为 Oracle 的标识符默认会转成大写存储。你如果真的用双引号建了一个小写名字的表空间，后续所有引用都必须带双引号，一次忘了就报“对象不存在”，而且各种运维脚本导出之后全是带引号的怪名字，排查时非常费神。

至于中文名和特殊字符，直接放弃。数据库里能用，但到了备份脚本、监控采集、跨库迁移环节，各种编码问题会层出不穷，收益为零。

2.4 容量与扩展策略的取舍表

自动扩展这块，我把常见的三种配置和适用场景整理成一张表，实际选型照着对就行：

我的默认选择是中间那档：开自动扩展，但一定设 MAXSIZE。这个值怎么定？拿预估年增量乘以 2 到 3，再取个整数。比如预估年增 5G，就设 10G 或 15G。设了上限之后，写满之前有充足的时间做扩容决策，而不是半夜被电话叫起来看磁盘 100%。

3. 表空间创建：参数背后的真实含义

3.1 永久表空间的标准建法

一段常用的建法长这样，我逐行解释：

CREATE TABLESPACE CRM_DATA DATAFILE '/u01/app/oracle/oradata/ORCL/crm_data01.dbf' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE 10G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO DEFAULT COMPRESSION DISABLE;

SIZE 500M是初始大小，建完立刻占用磁盘，不是虚拟的，所以别一上来就写 10G，先用一个合理的起始值跑起来。

NEXT 100M是每次扩展的增量。这个值太小会导致频繁扩文件（每扩一次都是一次 IO 和元数据操作），太大又会在写满时浪费一大块空间。100M 到 500M 是我常用的区间，具体看单表写入的批量大小。

MAXSIZE 10G是硬上限，前面说过了，必设。

EXTENT MANAGEMENT LOCAL是本地管理区的区分配方式，由 Oracle 通过位图在数据文件头部维护，不依赖数据字典，性能和并发都比老的字典管理方式好得多。10g 之后这是默认值，基本不用改，但显式写出来能避免在低版本迁移脚本时出岔子。

SEGMENT SPACE MANAGEMENT AUTO是段空间的自动管理，用一个位图追踪数据块的使用状态，替代了老的 FREELIST 机制。它能减少高并发插入时的争用，一般不需要改成 MANUAL，除非你做的是特殊的大并发场景且有明确测试数据支撑。

DEFAULT COMPRESSION DISABLE只是显式关闭默认压缩，避免某些版本或模板里带了压缩选项导致页面行为异常。如果你的模块是归档类、读多写少的，也可以反过来开压缩，能显著省空间，代价是写入时的 CPU 开销。

3.2 大文件表空间什么时候值得用

当单个业务的数据量预期会突破小文件表空间的单文件上限时（这个上限受块大小影响，8K 块大约是 32G），有两条路：加多个数据文件，或者直接建 BIGFILE。

CREATE BIGFILE TABLESPACE CRM_HIST DATAFILE '/u01/app/oracle/oradata/ORCL/crm_hist01.dbf' SIZE 2G AUTOEXTEND ON NEXT 512M MAXSIZE 200G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO;

BIGFILE 的好处是一个表空间只对应一个数据文件，扩容用 RESIZE 而不是 ADD DATAFILE，不占用 db_files 额度，管理上清爽。代价是这个文件一旦损坏，影响面是整个表空间，没有小文件那种“部分可用”的缓冲余地。

所以我自己的判断标准是：历史归档、日志明细、时序类数据优先 BIGFILE；核心交易表继续用小文件表空间，单文件控制在 8G 到 16G，加文件的方式做扩容，恢复粒度更细。

3.3 临时表空间的单独规划

临时表空间是很多人的盲区。它主要承载排序、哈希连接、全局临时表这些操作产生的中间数据，和永久数据分开存储，且必须用 TEMPFILE：

CREATE TEMPORARY TABLESPACE CRM_TEMP TEMPFILE '/u01/app/oracle/oradata/ORCL/crm_temp01.dbf' SIZE 1G AUTOEXTEND ON NEXT 200M MAXSIZE 8G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M;

注意这里用的是TEMPFILE而不是 DATAFILE，写错了会直接语法错误。UNIFORM SIZE 1M让所有区大小固定，临时段的分配回收更规整，避免大小不一的碎片。

临时表空间扩容的典型症状是ORA-01652: 无法通过 128 扩展临时段，看到这个报错不用慌，先查是谁在吃临时空间：

SELECT s.sid, s.serial#, s.username, s.sql_id, u.tablespace, u.blocks * 8 / 1024 AS mb_used FROM v$session s JOIN v$tempseg_usage u ON s.saddr = u.session_addr ORDER BY mb_used DESC;

经常是某条 SQL 用了超大的排序区或者错误的连接方式，把临时表空间瞬间撑爆。这种情况下加空间只是缓解，根子还在 SQL 上。

注意：临时表空间不要和永久表空间放在同一个高 IO 的挂载点上。排序操作是突发性的顺序 IO，容易把在线交易的响应时间带偏。

3.4 UNDO 的配套考虑

完整的一套表空间规划里，UNDO 也得提一句。新模块如果只是加一个业务用户，直接复用现有的 UNDO 表空间就行，不需要单独建。UNDO 是实例级共享的，按业务拆分反而会让回滚段管理变复杂。

只有当模块有超长的批量事务（比如一次处理几十万行的大更新）时，才需要关注 UNDO 表空间是否够用，以及undo_retention参数是否要调大。这部分属于事务设计层面，建用户阶段先记录需求，跑起来之后再观察 v$undostat 的实际消耗。

4. 创建用户：把“默认”两个字落实到具体值

4.1 CREATE USER 的每个子句都在解决一个问题

标准写法如下：

CREATE USER crm_app IDENTIFIED BY "App#2024Pwd" DEFAULT TABLESPACE CRM_DATA TEMPORARY TABLESPACE CRM_TEMP QUOTA UNLIMITED ON CRM_DATA PROFILE DEFAULT ACCOUNT UNLOCK;

IDENTIFIED BY后面跟密码。从 11g 开始密码默认大小写敏感，特殊字符在密码里是允许的，但如果通过命令行工具连接，特殊字符容易被 shell 解释掉，所以实际部署时我只用字母、数字和少量安全符号，并且一定用双引号包起来，避免解析歧义。

DEFAULT TABLESPACE决定这个用户建表时默认落在哪。这是最容易被忽略的一项：如果不指定，会用数据库的默认永久表空间（通常是 USERS），你辛苦规划的表空间就白搭了。

TEMPORARY TABLESPACE同理，不指定会用默认临时表空间。多业务共用一个 TEMP 在生产上是常见的，但如果你给模块单独建了 CRM_TEMP，这里一定要指过去。

QUOTA UNLIMITED ON CRM_DATA是配额，也就是这个用户在指定表空间上最多能占多少。这是最容易出事的地方：QUOTA 为 0 时用户能建表（只要有 CREATE TABLE 权限），但插入第一条数据就报ORA-01950: 对表空间 'XXX' 无权限。很多人第一次遇到会以为是权限没授对，其实是配额没给。

PROFILE DEFAULT使用默认的密码策略配置文件。生产环境建议单独建一个 profile，把密码有效期、失败锁定次数设成符合规范的值。

ACCOUNT UNLOCK确保账户立即可用。部分环境的安全模板会把新建用户默认置为锁定状态，加上这句省一次排查。

4.2 配额为什么建议设成有限值而不是 UNLIMITED

上面脚本里我写了 UNLIMITED，是为了演示简单。生产环境我更推荐给一个明确的上限：

ALTER USER crm_app QUOTA 5G ON CRM_DATA; ALTER USER crm_app QUOTA 0 ON SYSTEM;

理由是配额是这个用户能撑爆表空间的最后一道闸门。表空间本身的 MAXSIZE 是整个模块共享的上限，而配额是单用户的边界。给每个用户设配额，等于做了一次内部的资源隔离：一个用户跑飞了，最多吃掉自己那份，不会把同表空间的其他用户一起拖垮。

QUOTA 0 ON SYSTEM这条尤其重要。系统表空间绝对不应该让业务用户写入，一旦业务对象错误地建到了 SYSTEM 上，后期的空间管理和备份策略都会跟着乱。

修改已有用户的配额也是同样的语法，另外记得每次给用户新增表空间使用权时同步检查配额，否则新建的索引表空间会因为没配额而写入失败。

4.3 密码策略与账户状态

默认 profile 的密码策略往往太宽松或者太严格，两端都不合适。我会单独建一个：

CREATE PROFILE crm_profile LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1 PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 7 PASSWORD_REUSE_MAX 5 SESSIONS_PER_USER 20;

FAILED_LOGIN_ATTEMPTS 5加PASSWORD_LOCK_TIME 1，连续输错 5 次锁 1 天。这个组合能挡住暴力尝试，又不至于把正常用户长期锁死。PASSWORD_LIFE_TIME 90配合 7 天宽限期，到期前会给提示，宽限期内还能改。

这里有个坑要说清楚：应用连接池用的账号如果密码到期，整个应用会瞬间全部连不上，报ORA-28001: 密码已失效。所以业务账号的密码策略要和应用侧的改密流程配套，最好是走定期轮换机制，而不是等它自己过期。我见过不止一次因为没规划改密，导致业务在某个周末集体不可用。

账户状态用下面这句随时能看：

SELECT username, account_status, expiry_date, default_tablespace, temporary_tablespace, profile FROM dba_users WHERE username = 'CRM_APP';

account_status出现LOCKED(TIMED)说明是被策略锁的，EXPIRED(GRACE)说明密码过期还在宽限期，OPEN才是正常。

5. 授权：授到刚好够用，不多一分

5.1 系统权限：先从最小集开始试

业务用户建完，第一件事是给他登录权限，否则连不上：

GRANT CREATE SESSION TO crm_app;

很多老教程会直接写GRANT CONNECT, RESOURCE TO xxx，我建议你别这么干。CONNECT 在现在的版本里基本等同于 CREATE SESSION，没什么额外价值；RESOURCE 则包含了一堆你可能根本不需要的权限，比如建存储过程、建触发器、建类型、建集群。业务账号如果有 CREATE PROCEDURE，理论上具备在数据库里执行任意 PL/SQL 的能力，这在安全审计里是会被挑出来的。

我的做法是按需列清单：

-- 基础连接 GRANT CREATE SESSION TO crm_app; -- 建表、建序列、建视图 GRANT CREATE TABLE, CREATE SEQUENCE, CREATE VIEW TO crm_app; -- 需要建索引时（很多场景表空间配额已包含） GRANT CREATE ANY INDEX TO crm_app; -- 谨慎，建议只在明确需要时授予 -- 需要建同义词 GRANT CREATE SYNONYM TO crm_app;

CREATE ANY INDEX是个值得警惕的权限，它允许在其他 schema 的表上建索引，实际业务里通常不需要。绝大多数情况下，用户在自己 schema 下的表上建索引只需要CREATE TABLE加上对应表空间的配额就够了。

授完立刻回查，确认没有多授：

SELECT privilege, admin_option FROM dba_sys_privs WHERE grantee = 'CRM_APP' ORDER BY privilege;

admin_option这一列如果出现 YES，意味着这个用户可以把这个权限继续转授给别人，业务账号上出现这个值基本可以判定为配置错误。

5.2 角色授权和对象权限的分界线

系统权限管“能做什么动作”，对象权限管“能操作谁的数据”。角色是把一组权限打包，方便批量管理。

我常见的做法是建两个自定义角色，一个给应用读写，一个给运维只读：

-- 读写角色 CREATE ROLE crm_rw; GRANT SELECT, INSERT, UPDATE, DELETE ON crm_app.orders TO crm_rw; GRANT SELECT, INSERT, UPDATE, DELETE ON crm_app.order_items TO crm_rw; -- 只读角色 CREATE ROLE crm_ro; GRANT SELECT ON crm_app.orders TO crm_ro; GRANT SELECT ON crm_app.order_items TO crm_ro; -- 把角色授予具体账号 GRANT crm_rw TO app_account; GRANT crm_ro TO report_account;

用角色的好处是，新增一张表需要开放权限时，改角色就行，不用挨个账号去授。而且账号和权限之间多了一层映射，审计时更清楚谁因为什么角色拿到了什么权限。

对象权限里有个WITH GRANT OPTION，意思是拿到权限的人可以继续转授。除非你非常确定需要级联授权，否则别加。加了之后权限传播路径很难追踪，出问题时你甚至不知道是哪个环节漏出去的。对应地，系统权限里的WITH ADMIN OPTION风险更大，因为它授出去的是“管理能力”而不是“数据访问能力”。

注意：给角色授权时，如果对象所在的 schema 和授权人不同，需要用SYSDBA或者具备相应对象权限的账号执行，否则会报 ORA-01031。

5.3 默认角色和角色启用

一个用户被授予多个角色时，登录后默认全部启用。但有些系统出于控制考虑，会把某些角色设为非默认，需要显式启用才能生效：

-- 设为非默认角色 ALTER USER app_account DEFAULT ROLE crm_ro; -- 会话内手动启用 SET ROLE crm_rw;

查当前会话实际生效的角色：

SELECT * FROM SESSION_ROLES;

这一句我强烈建议所有排查权限问题的人先跑一遍。因为经常出现“明明授了权限还是报错”的情况，一查会话角色发现压根没启用，白折腾半小时。

6. 完整脚本与验证清单

6.1 一份可以直接改参数执行的脚本

把前面的内容串成一个完整的流程，注意按顺序执行：

-- 0. 切容器（多租户环境需要） -- ALTER SESSION SET CONTAINER = pdb_name; -- 1. 建永久表空间 CREATE TABLESPACE CRM_DATA DATAFILE '/u01/app/oracle/oradata/ORCL/crm_data01.dbf' SIZE 500M AUTOEXTEND ON NEXT 100M MAXSIZE 10G EXTENT MANAGEMENT LOCAL SEGMENT SPACE MANAGEMENT AUTO; -- 2. 建临时表空间 CREATE TEMPORARY TABLESPACE CRM_TEMP TEMPFILE '/u01/app/oracle/oradata/ORCL/crm_temp01.dbf' SIZE 1G AUTOEXTEND ON NEXT 200M MAXSIZE 8G EXTENT MANAGEMENT LOCAL UNIFORM SIZE 1M; -- 3. 建 profile CREATE PROFILE crm_profile LIMIT FAILED_LOGIN_ATTEMPTS 5 PASSWORD_LOCK_TIME 1 PASSWORD_LIFE_TIME 90 PASSWORD_GRACE_TIME 7 SESSIONS_PER_USER 20; -- 4. 建用户并挂配额 CREATE USER crm_app IDENTIFIED BY "App#2024Pwd" DEFAULT TABLESPACE CRM_DATA TEMPORARY TABLESPACE CRM_TEMP QUOTA 5G ON CRM_DATA QUOTA 0 ON SYSTEM PROFILE crm_profile ACCOUNT UNLOCK; -- 5. 授系统权限（按最小集） GRANT CREATE SESSION, CREATE TABLE, CREATE SEQUENCE, CREATE VIEW, CREATE SYNONYM TO crm_app; -- 6. 建角色并授对象权限（对象需已存在） -- CREATE ROLE crm_rw; -- GRANT SELECT, INSERT, UPDATE, DELETE ON crm_app.orders TO crm_rw; -- GRANT crm_rw TO app_account;

执行完之后不要急着交给应用，下面这套验证必须走一遍。

6.2 验证脚本：五个检查点

第一，确认表空间和数据文件状态：

SELECT t.tablespace_name, t.status, t.contents, d.file_name, d.bytes / 1024 / 1024 AS size_mb, d.autoextensible, d.maxbytes / 1024 / 1024 AS max_mb FROM dba_tablespaces t JOIN dba_data_files d ON t.tablespace_name = d.tablespace_name WHERE t.tablespace_name IN ('CRM_DATA', 'CRM_TEMP');

status 应该是 ONLINE，contents 对永久表空间是 PERMANENT，对临时表空间是 TEMPORARY。如果看到 OFFLINE 或者 READ ONLY，说明建的时候带了意外选项。

第二，确认用户属性：

SELECT username, default_tablespace, temporary_tablespace, account_status, profile FROM dba_users WHERE username = 'CRM_APP';

第三，确认配额：

SELECT tablespace_name, bytes / 1024 / 1024 AS used_mb, max_bytes / 1024 / 1024 AS quota_mb FROM dba_ts_quotas WHERE username = 'CRM_APP';

max_bytes 显示 -1 表示 UNLIMITED，其他数值就是实际配额。这里如果查不到记录，说明配额那一句没生效，回去补ALTER USER ... QUOTA ...。

第四，确认权限：

SELECT privilege, admin_option FROM dba_sys_privs WHERE grantee = 'CRM_APP'; SELECT granted_role, default_role FROM dba_role_privs WHERE grantee = 'CRM_APP';

第五，用新用户实际登录一次并建一张测试表，这是最有效的验证，比看多少次视图都管用：

-- 用 crm_app 登录后执行 CREATE TABLE t_smoke_test (id NUMBER, memo VARCHAR2(100)); INSERT INTO t_smoke_test VALUES (1, 'ok'); COMMIT; SELECT * FROM t_smoke_test; DROP TABLE t_smoke_test;

能建、能写、能查、能删，四步全过，说明表空间、配额、权限链路完全打通。这五步我一般会整理成一个小脚本存档，下次新建模块直接改参数跑。

7. 报错实录与排查速查

7.1 高频报错对照表

这几年处理过的问题里，八成都集中在这几个错误码上：

表格里出现频率最高的是前两个。ORA-01950 和 ORA-01653 看起来都像空间问题，但根子完全不同：前者是用户层面的配额，后者是表空间层面的文件大小。分清这一点能省很多时间，判断方法是查一下 dba_ts_quotas，如果配额正常，那就是文件到顶了。

7.2 扩容的正确姿势和顺序

确认是文件到顶之后，扩容有三个动作，按代价从小到大排：

-- 方式一：调整现有文件上限（最轻量，不改文件数） ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/crm_data01.dbf' AUTOEXTEND ON NEXT 200M MAXSIZE 20G; -- 方式二：直接扩展现有文件大小 ALTER DATABASE DATAFILE '/u01/app/oracle/oradata/ORCL/crm_data01.dbf' RESIZE 4G; -- 方式三：新增数据文件（受 db_files 限制） ALTER TABLESPACE CRM_DATA ADD DATAFILE '/u01/app/oracle/oradata/ORCL/crm_data02.dbf' SIZE 2G AUTOEXTEND ON NEXT 100M MAXSIZE 10G;

顺序上先试方式一，只是把上限抬高，不动文件，风险最低。如果磁盘确实还有空间而数据文件本身也接近文件系统限制，再走方式三。不建议一次性把 MAXSIZE 设成 UNLIMITED 来“一劳永逸”，等于把保护机制拆了。

7.3 删除和回收：别在生产上想当然

最后说删除，因为每年都有人在这上面翻车。

-- 删用户，级联删除其所有对象 DROP USER crm_app CASCADE; -- 删表空间，连带数据文件和内容 DROP TABLESPACE CRM_DATA INCLUDING CONTENTS AND DATAFILES;

顺序必须是先删用户，再删表空间。反过来做，用户还在但默认表空间没了，这个用户后续任何建表操作都会失败，状态变得很别扭。

INCLUDING CONTENTS AND DATAFILES 会真的删掉操作系统上的文件，这一步没有回收站。执行之前一定要确认三件事：这个表空间里没有其他 schema 的对象、已经做过备份、当前不在业务高峰期。我自己的习惯是，先执行DROP TABLESPACE CRM_DATA INCLUDING CONTENTS;（只删内容保留文件），观察一两天确认没有任何应用报错，再去手工删文件。多花一天，换的是不可逆操作的安全边际。

还有一种情况是表空间处于 OFFLINE 状态导致删不掉，需要先ALTER TABLESPACE CRM_DATA OFFLINE再执行删除，或者用DROP TABLESPACE ... INCLUDING CONTENTS AND DATAFILES直接带掉。

7.4 几条从实践里磨出来的经验

第一条，建表空间之前先看一眼告警日志。有些环境磁盘已经接近警戒线，你建了个 500M 的文件，把水位推过了阈值，监控立刻报警，虽然没出事但会引发一轮不必要的排查。

第二条，把建库脚本纳入版本管理。我见过太多环境，表空间参数只存在于某个人几年前的终端历史里，换人接手完全是黑盒。脚本入库，参数变更留记录，后面迁移或重建时能省下大量时间。

第三条，给配额留出余量而不是卡着实际用量设。有人算得很精，实际用 4.2G 就设 4.3G，结果一次批量导入直接撞墙。建议按当前用量的 1.5 到 2 倍设置，并且把"检查配额水位"纳入日常巡检。

第四条，临时表空间别设 UNLIMITED。排序操作的峰值是不可预测的，一条写错的 SQL 能在几分钟内吃掉几十 G 临时空间。设个上限，让它报错，总比把整台机器的磁盘写满、连带影响其他实例要好得多。

第五条，新建用户后立刻用该用户完整跑一遍业务主流程，而不是只做 SELECT 1 这种连接测试。权限授漏往往出现在具体某张表的某一种操作上，只有真实业务动作才能暴露。我曾经漏授过一张字典表的 SELECT，连接测试全过，应用跑起来第一步就报错，白白多等了一轮发布窗口。