ROWID是base64编码的二进制物理地址，不可用SUBSTR直接截取文件号；必须用DBMS_ROWID.ROWID_RELATIVE_FNO等函数解析，且返回的是相对文件号，需与v$datafile.relative_fno关联。
ROWID不是字符串，不能直接SUBSTR提取文件号
看到类似AAAMfPAAEAAAAAgAAA的值，别急着用SUBSTR(rowid, 7, 3)去截取“文件号”——这会出错。因为ROWID是base64编码的二进制地址，SUBSTR操作的是编码后的字符序列，不是原始字节结构，第7–9位在编码后不对应相对文件号的十进制值。
常见错误现象：SELECT SUBSTR(ROWID, 7, 3) FROM emp 返回AAB，但实际文件号是2；用TO_NUMBER('AAB')直接报ORA-01722。
正确做法是交由Oracle解析引擎处理：
- 必须传入
ROWID类型值，不能传字符串字面量（如DBMS_ROWID.ROWID_RELATIVE_FNO('AAAMfPAAEAAAAAgAAA')会报ORA-01428） - 函数返回整数，可直接用于
JOIN、WHERE或算术运算 - 注意：返回的是相对文件号（
relative_fno），不是v$datafile.file#
用DBMS_ROWID.ROWID_RELATIVE_FNO关联v$datafile找真实路径
DBMS_ROWID.ROWID_RELATIVE_FNO(t.rowid)给出的是相对文件号，它和v$datafile.relative_fno对齐，而非file#。忽略这点会导致查不到文件路径。
典型联查写法：
SELECT t.ename,
t.rowid,
rfile#,
d.file_name,
d.tablespace_name
FROM emp t,
v$datafile d
WHERE d.relative_fno = DBMS_ROWID.ROWID_RELATIVE_FNO(t.rowid);关键点：
- 不要用
d.file# = ...，那是绝对文件号，和ROWID不匹配 - 如果查询结果为空，先确认
v$datafile.relative_fno是否非空（某些只读表空间可能未加载） - 该查询需有
SELECT_CATALOG_ROLE或SELECT ANY DICTIONARY权限
ROWID_TO_CHAR结果里第7–9位才是真正的相对文件号（十进制）
DBMS_ROWID.ROWID_TO_CHAR(t.rowid)返回18位固定格式字符串，形如AAAAfGAABAAAAZKAAA，其中第7–9位（从1开始计）是**十进制数字**，直接对应相对文件号。
例如：AAAAfGAABAAAAZKAAA → 第7–9位是AAB？不对——这是误解。实际应为002这类纯数字。若看到字母，说明你传入了错误格式的值，或该ROWID来自旧版本限制格式（已基本绝迹）。
安全验证方式：
- 执行
SELECT DUMP(DBMS_ROWID.ROWID_TO_CHAR(rowid)) FROM emp WHERE ROWNUM = 1，确认输出类型是TYP=96（CHAR）且内容全为ASCII数字 - 对比
DBMS_ROWID.ROWID_RELATIVE_FNO(rowid)与SUBSTR(DBMS_ROWID.ROWID_TO_CHAR(rowid), 7, 3)，二者必须相等 - 若不等，说明该ROWID已被移动（如执行过
ALTER TABLE ... MOVE），此时ROWID已失效
ROWID会变，别把它当长期主键存
只要发生以下任一操作，ROWID就不可再用：
-
ALTER TABLE ... MOVE或SHRINK SPACE - 分区表的
SPLIT/EXCHANGE操作 - 启用行迁移（
UPDATE导致行变长且原块放不下）
所以，即使你成功定位到某行在/u01/oradata/DB12C/users01.dbf的第32号块，也不能把AAAMfPAAEAAAAAgAAA写死在应用配置里。它只在当前事务或短时诊断中可靠。
最易被忽略的一点：SELECT FOR UPDATE之后拿到的ROWID，在另一个会话里执行UPDATE ... WHERE ROWID = :rid前，必须确保该行未被其他事务移动或删除——否则语句不报错但影响0行。
