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 还是 PDB12c 及以上 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 容量与扩展策略的取舍表自动扩展这块我把常见的三种配置和适用场景整理成一张表实际选型照着对就行配置方式语法要点优点风险适用场景不自动扩展不写 AUTOEXTEND空间完全可控不会突然打满磁盘需要人工监控扩容写满即报错核心交易库、容量稳定且有人值守有限自动扩展AUTOEXTEND ON NEXT 100M MAXSIZE 10G兼顾弹性和上限保护需预估上限估小了会提前写满绝大多数业务表空间无限自动扩展AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED省心短期不会写满可能撑爆磁盘影响整机仅限非关键库或临时环境我的默认选择是中间那档开自动扩展但一定设 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 临时表空间的单独规划临时表空间是很多人的盲区。它主要承载排序、哈希连接、全局临时表这些操作产生的中间数据和永久数据分开存储且必须用 TEMPFILECREATE 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 应该是 ONLINEcontents 对永久表空间是 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-01950no privileges on tablespace用户在该表空间上配额为 0 或未分配ALTER USER u QUOTA 1G ON ts;ORA-01653unable to extend table表空间数据文件达到 MAXSIZE 或磁盘满加数据文件、RESIZE 或扩大 MAXSIZEORA-01652unable to extend temp segment临时表空间不足加 TEMPFILE 或优化大排序 SQLORA-01119error in creating database file目录不存在或无写权限主机侧确认目录和属主ORA-01543tablespace already exists对象重名换名或先 DROPORA-01045user lacks CREATE SESSION未授予登录权限GRANT CREATE SESSION TO u;ORA-28000the account is locked触发失败登录锁定策略ALTER USER u ACCOUNT UNLOCK;ORA-28001the password has expired密码超过有效期重置密码或调整 profileORA-01144file size exceeds maximum超过小文件表空间单文件上限加数据文件或改用 BIGFILE表格里出现频率最高的是前两个。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连接测试全过应用跑起来第一步就报错白白多等了一轮发布窗口。 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 还是 PDB12c 及以上 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 容量与扩展策略的取舍表自动扩展这块我把常见的三种配置和适用场景整理成一张表实际选型照着对就行配置方式语法要点优点风险适用场景不自动扩展不写 AUTOEXTEND空间完全可控不会突然打满磁盘需要人工监控扩容写满即报错核心交易库、容量稳定且有人值守有限自动扩展AUTOEXTEND ON NEXT 100M MAXSIZE 10G兼顾弹性和上限保护需预估上限估小了会提前写满绝大多数业务表空间无限自动扩展AUTOEXTEND ON NEXT 100M MAXSIZE UNLIMITED省心短期不会写满可能撑爆磁盘影响整机仅限非关键库或临时环境我的默认选择是中间那档开自动扩展但一定设 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 临时表空间的单独规划临时表空间是很多人的盲区。它主要承载排序、哈希连接、全局临时表这些操作产生的中间数据和永久数据分开存储且必须用 TEMPFILECREATE 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 应该是 ONLINEcontents 对永久表空间是 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-01950no privileges on tablespace用户在该表空间上配额为 0 或未分配ALTER USER u QUOTA 1G ON ts;ORA-01653unable to extend table表空间数据文件达到 MAXSIZE 或磁盘满加数据文件、RESIZE 或扩大 MAXSIZEORA-01652unable to extend temp segment临时表空间不足加 TEMPFILE 或优化大排序 SQLORA-01119error in creating database file目录不存在或无写权限主机侧确认目录和属主ORA-01543tablespace already exists对象重名换名或先 DROPORA-01045user lacks CREATE SESSION未授予登录权限GRANT CREATE SESSION TO u;ORA-28000the account is locked触发失败登录锁定策略ALTER USER u ACCOUNT UNLOCK;ORA-28001the password has expired密码超过有效期重置密码或调整 profileORA-01144file size exceeds maximum超过小文件表空间单文件上限加数据文件或改用 BIGFILE表格里出现频率最高的是前两个。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连接测试全过应用跑起来第一步就报错白白多等了一轮发布窗口。