数据库open报ORA-00959: tablespace ‘UNDOTBS1′ does not exist分析

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:数据库open报ORA-00959: tablespace ‘UNDOTBS1′ does not exist分析

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

有一个朋友找到我,说数据库重启之后无法正常启动,提示ORA-00959 UNDOTBS1表空间不存在
ORA-00959-undotbs1


在数据库的启动过程中,这个是一个很常见的错误,一般出现这类错误的原因是由于undo_tablespace指定的undo表空间不存在导致.但是这个库比较明显,设置了undo_management=manual, undo_tablespace=system,依旧数据库需要找undotbs1表空间,进一步分析数据库当前表空间情况
20220508224920

该数据库确实没有undotbs1表空间,基于以上信息,初步怀疑很可能是undo回滚段异常,通过对于oracle基表进行分析,发现信息
undo-tbs
undotbs1

基于上面的信息,可以确认回滚段中确实有四条记录指向被删除的undotbs1,而且还有一条undo回滚段信息为need recovery状态.进一步分析数据库alert日志

--创建undotbs2表空间,并重启数据库
Sun Sep 26 14:42:16 2021
create undo tablespace UNDOTBS2 datafile '/data/oradata/xifenfei/undotbs001.dbf' size 120G
reuse autoextend on next 500m maxsize unlimited
Sun Sep 26 14:46:46 2021
Completed: create undo tablespace UNDOTBS2 datafile '/data/oradata/xifenfei/undotbs001.dbf' size 120G
reuse autoextend on next 500m maxsize unlimited
Sun Sep 26 14:47:13 2021
[16927] Successfully onlined Undo Tablespace 10.
[16927] **** active transactions found in undo Tablespace 2 - moved to Pending Switch-Out state.
[16927] active transactions found/affinity dissolution incompletein undo tablespace 2 during switch-out.
ALTER SYSTEM SET undo_tablespace='UNDOTBS2' SCOPE=BOTH;
Sun Sep 26 14:49:25 2021
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process QMNC

---第一次尝试删除undotbs1失败
Sun Sep 26 15:06:30 2021
drop tablespace UNDOTBS1 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
Sun Sep 26 15:47:26 2021
ORA-1013 signalled during: drop tablespace UNDOTBS1 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
...
Sun Sep 26 15:48:40 2021
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process QMNC

--加上该隐含参数,继续重启库删除undotbs1,依旧删除失败
  _corrupted_rollback_segments= "_SYSSMU28_1306132068$"

Sun Sep 26 15:53:34 2021
QMNC started with pid=31, OS id=20454 
Completed: ALTER DATABASE OPEN
Sun Sep 26 15:55:32 2021
 drop tablespace UNDOTBS1 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
…………
Sun Sep 26 16:45:47 2021
ORA-1013 signalled during:  drop tablespace UNDOTBS1 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS...
Sun Sep 26 16:46:00 2021
Shutting down instance (immediate)
Shutting down instance: further logons disabled
Stopping background process QMNC

---加上以下参数,并尝试重启数据库删除undotbs1成功
  _corrupted_rollback_segments= "_SYSSMU31_201790566$"
  _corrupted_rollback_segments= "_SYSSMU30_2395098326$"
  _corrupted_rollback_segments= "_SYSSMU29_306369076$"
  _corrupted_rollback_segments= "_SYSSMU28_1306132068$"

Sun Sep 26 16:47:24 2021
QMNC started with pid=31, OS id=23421 
Completed: ALTER DATABASE OPEN
Sun Sep 26 16:47:40 2021
drop tablespace UNDOTBS1 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS
…………
Mon Sep 27 01:44:56 2021
Deleted file /data/oradata/xifenfei/undotbs01.dbf
Deleted file /data/oradata/xifenfei/undotbs02.dbf
Deleted file /data/oradata/xifenfei/undotbs03.dbf
Deleted file /data/oradata/xifenfei/undotbs04.dbf
Deleted file /data/oradata/xifenfei/undotbs05.dbf
Deleted file /data/oradata/xifenfei/undotbs06.dbf
Completed: drop tablespace UNDOTBS1 INCLUDING CONTENTS AND DATAFILES CASCADE CONSTRAINTS

从这里基本上可以看出来,操作之人非常草率,在oracle回滚段还在被占用状态,直接尝试删除老undo表空间,在无法删除之后,直接暴力的使用undo回滚段异常参数,然后进行undo表空间删除.这样操作的后果屏蔽了事务的一致性,导致后续可能导致数据库一系列异常.对当前库启动过程进行跟踪发现
20220511192523


数据库启动的过程中查询undo$中的undotbs1信息,而该表空间不存在,所以出现此类报错,从而导致数据库无法正常启动.知道问题原因所在,那通过undo$记录,数据库即可正常启动.

ASM删除表空间恢复

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ASM删除表空间恢复

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

前几天刚刚恢复了一个文件系统层面drop 表空间的case(分享运气超级好的一次drop tablespace 数据恢复),又一客户删除表空间(认为是不要的表空间),结果发现业务上丢失了很多表数据,通过分析和回顾以往事件,确认由于在以前数据迁移过来的过程中,数据写入了和原库一致的表空间,而没有恢复到本该恢复的新表空间中,这次删除该空间导致很多表数据丢失.而且该客户是asm环境,drop tablespace带上了including contents and datafiles语句,导致该表空间对应的数据文件也丢失.对于这类数据的恢复,一般情况下先通过asm层面恢复出来被删除的数据文件,然后再对被删除的数据文件按照丢失system的方式恢复里面的表数据(这个客户有历史备份便于整合)
在恢复被删除的文件之前,需要先确认对应的被删除的表空间信息和对应的文件信息,通过对底层字典分析file$,ts$,结合alert日志,可以确认被删除文件的文件号,文件名称等信息
20220510122726
由于文件已经从asm磁盘组中删除,无法直接恢复,通过对asm磁盘组进行扫描找出对应的block信息,参考:asm磁盘组操作不当导致数据文件丢失恢复类似处理方法,分析文件是否异常
20220510124206
初步判断文件恢复效果应该不错,恢复出来数据文件,然后进行dbv检查
20220510130244
20220507125013


后续的操作比较简单,使用oracle dul恢复出来按照类似方法:dul恢复drop表测试 数据即可,业务进行核对即可.如果你遭遇到此类情况,而且无有效备份,尽可能保护现场(不要对asm/文件系统系统进行写入操作),然后联系我们进行处理,最大限度恢复数据

ORA-12518 ORA-27302: 错误发生在: ssthrddcr

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:ORA-12518 ORA-27302: 错误发生在: ssthrddcr

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

11.2.0.1数据库运行在win 2008机器上,进程数配置为1000,但是数据库连接数到了170多之后,就开始报ORA-12518 TNS:监听程序无法分发客户机连接
ORA-12518


检查alert日志发现后台日志报ORA-27300 ORA-27301 ORA-27302错误

Fri May 06 11:57:14 2022
Process startup failed, error stack:
Errors in file c:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_psp0_3052.trc:
ORA-27300: 操作系统系统相关操作: CreateThread 失败, 状态为: 8
ORA-27301: 操作系统故障消息: 存储空间不足,无法处理此命令。
ORA-27302: 错误发生在: ssthrddcr
Process J002 died, see its trace file
kkjcre1p: unable to spawn jobq slave process 
Errors in file c:\app\administrator\diag\rdbms\orcl\orcl\trace\orcl_cjq0_3808.trc:

通过mos分析确认问题为IRPStackSize参数值问题
irpstacksize


参考:Ora-27300: OS System Dependent Operation:Createthread Failed With Status: 8 (Doc ID1310453.1)

plsql 插入blob

联系:手机/微信(+86 17813235971) QQ(107644445)QQ咨询惜分飞

标题:plsql 插入blob

作者:惜分飞©版权所有[未经本人同意,不得以任何形式转载,否则有进一步追究法律责任的权利.]

plsql 插入blob

SQL> create bigfile tablespace t_xifenfei datafile 'e:/oradata/orcl/t_blob.dbf' size 128M autoextend on;

表空间已创建。


SQL> create table u0425.t_blob(a int, b varchar(10), c blob) tablespace t_xifenfei ;

表已创建。


SQL> create or replace directory expdp_dir as 'e:/';

目录已创建。


SQL> declare
  2  b_file bfile;
  3  b_lob blob;
  4  begin
  5  insert into u0425.t_blob(a,b,c) values(1,'xifenfei', empty_blob()) return c into b_lob;
  6  b_file:=bfilename('EXPDP_DIR','0430.DMP');
  7  dbms_lob.open(b_file,dbms_lob.file_readonly);
  8  dbms_lob.loadfromfile(b_lob,b_file,dbms_lob.getlength(b_file));
  9  dbms_lob.close(b_file);
 10  commit;
 11  end;
 12  /

PL/SQL 过程已成功完成。

SQL> select * from u0425.t_blob where rownum<2;

         A B
---------- ----------
C
--------------------------------------------------------------------------------
         1 xifenfei
0301914E3B98006780BC00019FC70146A1A3633DBC4B089DCF3DFCD951D559000000010000100003
6907E6041E0D3037000000020200000077D10000000000FA1A880022535953222E225359535F4558


SQL> select a,b,dbms_lob.getlength(c) from u0425.t_blob where rownum<2;

         A B          DBMS_LOB.GETLENGTH(C)
---------- ---------- ---------------------
         1 xifenfei               142024704

插入的blob字段和实际文件大小,内容一致,插入是成功的
20220502164359
20220502164727