标签云
asm恢复 bbed bootstrap$ dul In Memory kcbzib_kcrsds_1 kccpb_sanity_check_2 MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-00742 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2131 ORA-600 2662 ORA-600 2663 ORA-600 3020 ORA-600 4000 ORA-600 4137 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kcbzib_kcrsds_1 ORA-600 KCLCHKBLK_4 ORA-15042 ORA-15196 ORACLE 12C oracle dul ORACLE PATCH Oracle Recovery Tools oracle加密恢复 oracle勒索 oracle勒索恢复 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 YOUR FILES ARE ENCRYPTED 勒索恢复 比特币加密文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (103)
- 数据库 (1,716)
- DB2 (22)
- MySQL (74)
- Oracle (1,576)
- Data Guard (52)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (160)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (68)
- Oracle Bug (8)
- Oracle RAC (54)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (28)
- Oracle备份恢复 (575)
- Oracle安装升级 (94)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (81)
- PostgreSQL (18)
- PostgreSQL恢复 (6)
- SQL Server (28)
- SQL Server恢复 (9)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (37)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (20)
-
最近发表
- 不当使用_allow_resetlogs_corruption参数引起ORA-600 2662错误
- CSSD signal 11 in thread clssnmRcfgMgrThread故障处理
- 使用sid方式直接访问pdb(USE_SID_AS_SERVICE_LISTENER)
- ORA-00069: cannot acquire lock — table locks disabled for xxxx
- ORA-600 [4000] [a]相关bug
- sql server数据库“正在恢复”故障处理
- 如何判断数据文件是否处于begin backup状态
- CDM备份缺少归档打开数据库报ORA-600 kcbzib_kcrsds_1故障处理
- ORA-07445: exception encountered: core dump [expgod()+43] [IN_PAGE_ERROR]
- 2025年第一起ORA-600 16703故障恢复
- _gc_undo_affinity=FALSE触发ORA-01558
- public授权语句
- 中文环境显示AR8MSWIN1256(阿拉伯语字符集)
- 处理 Oracle 块损坏
- Oracle各种类型坏块说明和处理
- fio测试io,导致磁盘文件系统损坏故障恢复
- ORA-742 写丢失常见bug记录
- Oracle 19c 202501补丁(RUs+OJVM)-19.26
- 避免 19c 数据库性能问题需要考虑的事项 (Doc ID 3050476.1)
- Bug 21915719 Database hang or may fail to OPEN in 12c IBM AIX or HPUX Itanium – ORA-742, DEADLOCK or ORA-600 [kcrfrgv_nextlwn_scn] ORA-600 [krr_process_read_error_2]
标签归档:ORA-01561
因非常规操作导致删除表空间提示ORA-01561解决办法
今天测试手工通过bbed修改undo$中回滚段状态(从status$=5修改为1)[NEEDS RECOVERY 修改为 DELETE],然后尝试删除表空间,发现不能删除
删除表空间提示ORA-01561
SQL> drop tablespace undotbs; drop tablespace undotbs * ERROR at line 1: ORA-01561: failed to remove all objects in the tablespace specified SQL> drop tablespace undotbs including contents; drop tablespace undotbs including contents * ERROR at line 1: ORA-01561: failed to remove all objects in the tablespace specified
查询相关信息
SQL> select ts#,name from v$tablespace; TS# NAME ---------- ------------------------------ 0 SYSTEM 1 SYSAUX 4 USERS 6 UNDOTBS 3 TEMP SQL> select name,ts#,status$ from undo$; NAME TS# STATUS$ ------------------------------ ---------- ---------- SYSTEM 0 3 _SYSSMU1_3138885392$ 2 1 _SYSSMU2_4228238222$ 2 1 _SYSSMU3_2210742642$ 2 1 _SYSSMU4_1455318006$ 2 1 _SYSSMU5_3787622316$ 2 1 _SYSSMU6_2460248069$ 2 1 _SYSSMU7_1924883037$ 2 1 _SYSSMU8_1909280886$ 2 1 _SYSSMU9_3593450615$ 2 1 _SYSSMU10_2490256178$ 2 1 NAME TS# STATUS$ ------------------------------ ---------- ---------- _SYSSMU11_253524401$ 6 1 _SYSSMU12_842775869$ 6 1 _SYSSMU13_2794767139$ 6 1 _SYSSMU14_2067649841$ 6 1 _SYSSMU15_3270221471$ 6 1 _SYSSMU16_4094338609$ 6 1 _SYSSMU17_709661646$ 6 1 _SYSSMU18_699588262$ 6 1 _SYSSMU19_718640828$ 6 1 _SYSSMU20_3516920665$ 6 1 _SYSSMU21_793796797$ 6 1 NAME TS# STATUS$ ------------------------------ ---------- ---------- _SYSSMU22_3988785920$ 6 1 _SYSSMU23_1828333848$ 6 1 _SYSSMU24_1223218862$ 6 1 _SYSSMU25_2939844199$ 6 1 _SYSSMU26_1317300205$ 6 1 _SYSSMU27_1654033223$ 6 1 _SYSSMU28_3748619502$ 6 1 _SYSSMU29_1868765904$ 6 1 _SYSSMU30_3379578723$ 6 1 31 rows selected. SQL> select segment_name,status from dba_rollback_segs; SEGMENT_NAME STATUS ------------------------------ ---------------- SYSTEM ONLINE
通过这里可以看出,通过bbed的修改,除system回滚段外,其他均已经被标志为delete状态,对于这样的情况,很本能的怀疑是extent或者segment未被清理掉导致
查询EXTENT和SEGMENT
SQL> select SEGMENT_NAME from dba_extents where TABLESPACE_NAME='UNDOTBS'; no rows selected SQL> select segment_name from dba_segments where TABLESPACE_NAME='UNDOTBS'; no rows selected SQL> select count(*) from seg$ where ts#=6; COUNT(*) ---------- 10 SQL> select count(*) from seg$ where ts#=2; COUNT(*) ---------- 0 SQL> select file#,type# from seg$ where ts#=6; FILE# TYPE# ---------- ---------- 3 10 3 10 3 10 3 10 3 10 3 10 3 10 3 10 3 10 3 10 10 rows selected.
通过查询我们发现SEG$中含有10条记录,而通过dbms_metadata.get_ddl分析DBA_SEGMENTS是的,得出type为10恰好是TYPE2 UNDO信息.
解决办法
删除掉这些因为手工修改undo$信息导致遗留下来的后遗症对象
SQL> delete from seg$ where ts#=6; 10 rows deleted. SQL> commit; Commit complete. SQL> drop tablespace undotbs ; Tablespace dropped.
这样的直接修改基表的做法,在一般的情况下非常不建议使用,可能带来系统不稳定.但是在数据库异常处理过程中,可能将成为一个法宝