分类目录归档：数据库

.mallox加密数据库恢复

发表于 2022 年 1 月 16 日 由 惜分飞

有客户数据库被加密,扩展名为:.mallox，对应的RECOVERY INFORMATION.txt文件信息
20220116002249

被加密数据文件情况
20220116001956
有oracle数据库的.dbf.mallox,sql server数据库的.mdf.mallox和.bak.mallox,通过底层分析，确认损坏的block不多
20220116001752
通过数据库层面技术处理,实现数据恢复
20220116002602
20220116002620
系统安全防护措施建议：
1.多台机器，不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性，并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制，并进行定期备份
4.定期检测系统和软件中的安全漏洞，及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件，并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件，如果已经被杀毒软件拦截查杀，不要添加信任继续运行。
9.保存良好的备份习惯，尽量做到每日备份，异地备份。

发表在 勒索恢复 | 标签为 , , , , , | 留下评论

ORA-600 6807恢复

发表于 2022 年 1 月 6 日 由 惜分飞

有朋友找到我,反馈说数据库登录报ORA-600 6807错误,希望我们给予解决
20220106225249

对于该错误有过一定的了解,一般是seq问题,这里报错比较明显是由于audses$序列出现问题导致数据库无法正常登录(因为数据库启动了审计,在登录之时会触发insert aud$操作,这个操作包含了audses$这个序列的调用,在调用这个序列的时候出现问题从而引起该问题),对其system数据文件dbv检查
20220106225405
比较明显有一个block被标记为坏块,通过对该block进行分析,确认刚好是seq$对象

DUL> rdba 4195465

  rdba   : 0x00400489=4195465
  rfile# : 1
  block# : 1161

DUL> desc sys.seq$


Object ID:100
Storage(Obj#=100 DataObj#=100 TS#=0 File#=1 Block#=1160 Cluster=0)

NO. SEG INT Column Name                    Null?     Type
--- --- --- ------------------------------ --------- ------------------------------
  1   1   1 OBJ#                           NOT NULL  NUMBER
  2   2   2 INCREMENT$                     NOT NULL  NUMBER
  3   3   3 MINVALUE                                 NUMBER
  4   4   4 MAXVALUE                                 NUMBER
  5   5   5 CYCLE#                         NOT NULL  NUMBER
  6   6   6 ORDER$                         NOT NULL  NUMBER
  7   7   7 CACHE                          NOT NULL  NUMBER
  8   8   8 HIGHWATER                      NOT NULL  NUMBER
  9   9   9 AUDIT$                         NOT NULL  VARCHAR2(38)
 10  10  10 FLAGS                                    NUMBER
 11  11  11 PARTCOUNT                                NUMBER

DUL> dump datafile 1 block 1160
Block Header:
block type=0x10 (data segment header block (unlimited extents))
block format=0xa2 (oracle 10+)
block rdba=0x00400488 (file#=1, block#=1160)
scn=0x0000.001a3fcd, seq=2, tail=0x3fcd1002
block checksum value=0xe280=57984, flag=4
Data Segment Header:
  Extent Control Header
  -------------------------------------------------------------
  Extent Header:: extents: 1  blocks: 7
                  last map: 0x00000000  #maps: 0  offset: 4128
      Highwater:: 0x0040048d  (rfile#=1,block#=1165)
                  ext#: 0  blk#: 4   ext size:7
      #blocks in seg. hdr's freelists: 1
      #blocks below: 4
      mapblk: 0x00000000   offset: 0
      Map Header:: next: 0x00000000   #extents: 1  obj#: 100  flag: 0x40000000
  Extent Control Header
  -------------------------------------------------------------
   0x00400489  length: 7

  nfl = 1, nfb = 1, typ = 1, nxf = 0, ccnt = 4
  SEG LST:: flg:  USED lhd: 0x0040048c ltl: 0x0040048c
DUL> rdba 0x00400489

  rdba   : 0x00400489=4195465
  rfile# : 1
  block# : 1161

DUL>

通过修复使用我们的Oracle recovery tools小工具，或者参考:校验代码为 6054 坏块故障修复进行修复,然后数据库用户可以正常登录
20220106230709

发表在 Oracle备份恢复 | 标签为 | 留下评论

2022年恢复第一单ORA-600 kokasgi1

发表于 2022 年 1 月 1 日 由 惜分飞

2022年第一个数据库恢复请求,数据库启动报ORA-00600 kokasgi1错误
20220101202040

这种错误已经有过大量的恢复经历,一般是由于数据库启动之时无法查询到SYS用户导致.
ORA-600 kokasgi1故障恢复
win环境报ora-600 kokasgi1处理
再次遇到ORA-600 kokasgi1故障恢复
重命名sys用户引起数据库启动报ORA-01092 ORA-00600 kokasgi1错误
通过特殊手段启动数据库,然后修改SYS
20220101201544
20220101202007
发表在 Oracle备份恢复 | 标签为 | 留下评论