文件系统损坏导致数据文件异常恢复

今天接到一个客户的服务请求,由于服务器被强制重启,数据库无法启动
ORA-1200报错
ora-1200


这是一个常见的ORA-1200错误,但是文件大小相差的有离谱实际大小729600个block,但是现在只有149760个block.不像是一般主机重启导致的数据库异常.通过再次咨询客户实际是什么情况,客户那边如实描述:三个磁盘的raid 5由于两个盘掉线,后来使用最后一个好的盘和最后掉线的盘,强制拉起raid,系统启动通过长时间的自检之后,就是出现这样的情况.通过进一步检查发现,发现大多数数据文件异常.
文件系统中数据文件截图
dbf-fs

通过查询数据库确定文件大小情况
df_header_check

对比文件系统中的文件和数据库查询结果,可以发现绿色框中的文件全部大于文件系统中文件,蓝色框中的文件在文件系统中丢失.对于这样的情况,由于被强制online的磁盘中有坏道,导致文件系统损坏,从而出现大量文件大小异常甚至文件丢失;或者是由于选择错了上线的磁盘出现该问题(通过分析存在的文件,判断确定上线的盘没有问题),那就是文件系统故障导致.
底层重组恢复
解决该问题的方法是通过底层block恢复,重组oracle数据文件,并且检查恢复文件坏块情况.参考:Oracle 数据文件大小为0kb或者文件丢失恢复
scan-disk

分析文件坏块原因
block-had

由于文件所在block被覆盖或者磁盘坏道导致这部分block直接被空块填充.
这个客户比较幸运,直接open数据库成功,坏坏块进行分析判断业务表空间数据文件的坏块全部为index,业务数据0丢失.

发表在 非常规恢复 | 标签为 , , , , | 留下评论

ogg导致v$logfile查询频繁

在某些版本的ogg中发现ogg抽取进程对v$logfile视图查询影响比较大
20181116220104


对应的sql语句为:SELECT 1 FROM V$LOGFILE WHERE(STATUS NOT IN (‘STALE’, ‘INVALID’) OR STATUS IS NULL) AND MEMBER <> :log_name AND EXISTS ( SELECT 1 FROM V$LOG WHERE GROUP# = V$LOGFILE.GROUP# AND THREAD# = :ora_thread AND SEQUENCE# = :ora_seq_no ) AND ROWNUM = 1
查询mos发现相关问题描述:Query On V$logfile Running Excessive Number Of Times After upgrading ogg to 11.2.1.0.32 or 12.1.2.1.5 or later (Doc ID 2116395.1)和Bug 22650790 : CE 12.1.2.1.9: Query on v$logfile running excessive number of times
2116395.1

根据mos描述在ogg对应版本中设置:TRANLOGOPTIONS _ENABLESTREAMLINEDDBLOGREADER

发表在 GoldenGate | 标签为 , | 留下评论

Oracle 11.2升级到18C

Oracle 18c是12.2的后续版本,不管是从稳定性还是企业级用户的对数据库使用习惯(一般不使用初始版)都是一个可以考虑的选择.另外从11.2的标准服务期限将在2018年底到
DBRoadmap


还有一些客户可能需要使用到一些新功能必须imdb,far sync dg等,考虑把11.2的数据库升级到oracle 18c,结合oracle官方升级文档,这里提供一个手工升级11.2到18c的参考文档:Oracle 18C Non-CDB手工升级文档
主要参考官方文档:Oracle DB 18c – Complete Checklist for Manual Upgrades to Non-CDB Oracle Database 18c(Doc ID 2418045.1)

发表在 Oracle安装升级 | 标签为 , | 留下评论

Oracle Database Server ‘TNS Listener’远程数据投毒漏洞(CVE-2012-1675)的解决方案

根据oracle mos官方描述,该问题需要打patch和配置同步进行,这篇主要提供单机Oracle Database Server ‘TNS Listener’远程数据投毒漏洞(CVE-2012-1675)的解决方案,参考文档Using Class of Secure Transport (COST) to Restrict Instance Registration (Doc ID 1453883.1),因为文档本身描述比较繁琐,这里对其进行简单总结:
数据库版本要求
包含12880299补丁,最低版本要求(高于以下版本即可)
12880299


通过$ORACL_HOME/OPatch/opatch lsinventory 命令获取版本信息,大于等于上述文档版本即可,具体版本对应关系参考:数据库补丁对应关系
listener.ora文件配置

LISTENER =
  (DESCRIPTION_LIST =
    (DESCRIPTION =
      (ADDRESS = (PROTOCOL = TCP)(HOST = localhost.localdomain)(PORT = 1521))
     # (ADDRESS = (PROTOCOL = IPC)(KEY = EXTPROC1521))  --注释掉,一般不会使用ipc,绝大部分应用使用tcp连接数据库
    )
  )

ADR_BASE_LISTENER = /home/u01/app/oracle
SECURE_REGISTER_LISTENER = (TCP)  --增加该参数

重启监听

lsnrctl stop
lsnrctl start

验证配置生效

1.查看数据库监听日志
$ORACLE_BASE/diag/tnslsnr/主机名/listener/trace/listener.log

2.在局域网中找一台数据库服务器(单机环境),登录数据库
Sqlplus / as sysdba
Show parameter remote_listener;--记录该值(一般是空)
alter system set remote_listener='(ADDRESS=(PROTOCOL=TCP)(HOST=ip)(PORT=1521))' scope=memory;
IP为修改为上述监听的数据库服务器地址

3.再次查看监听日志,会发现类似记录(亦可在数据库中之执行alter system register观察)
02-NOV-2018 20:37:53 * service_register_NSGR * 1194
TNS-01194: The listener command did not arrive in a secure transport
02-NOV-2018 20:37:56 * service_register_NSGR * 1194
TNS-01194: The listener command did not arrive in a secure transport
观察一会儿,表明我们的监听配置生效,数据库拒绝远程监听,修复该漏洞.
如果没有出现类似记录,请核查数据库版本补丁是否满足要求,listener.ora参数配置是否正确

4.还原remote_listener参数以前值
sqlplus / as sysdba
alter system set remote_listener='2中查询记录的值' scope=memory;

对于rac环境,配置比较复杂,参考mos文档:Using Class of Secure Transport (COST) to Restrict Instance Registration in Oracle RAC (Doc ID 1340831.1)

发表在 Oracle 监听 | 标签为 , | 留下评论

GANDCRAB V5.0.4 比特币加密oracle数据库恢复

接到朋友的恢复请求,win服务器文件被GANDCRAB V5.0.4的比特币勒索加密的oracle数据库(中联his[大量中文表名/xml类型]),让我们对其分析,判断是否可以恢复
3
4


通过工具对其分析,发现需要是文件头和数据文件空间使用位图相关block进行重构,主要业务数据理论上应该是好的.通过分析数据库表空间、数据文件等相关的数据库基础信息,通过人工重构,重建控制文件,经过一系列恢复,数据库强制open成功

SQL> select open_mode from v$database;

OPEN_MODE
--------------------
READ WRITE

SQL> select name from v$datafile;

NAME
--------------------------------------------------------------------------------
E:\ORCLNEW1\SYSTEM01.DBF.HKNWFZ
E:\ORCLNEW1\SYSAUX01.DBF.HKNWFZ
E:\ORCLNEW1\UNDOTBS01.DBF.HKNWFZ
E:\ORCLNEW1\USERS01.DBF.HKNWFZ
E:\ORCLNEW1\BHDATA.DBF.HKNWFZ
E:\ORCLNEW1\BHMAIL.DBF.HKNWFZ
E:\ORCLNEW1\BHINDEX.DBF.HKNWFZ
E:\ORCLNEW1\ZHBASIS.DBF.HKNWFZ
E:\ORCLNEW1\ZHARCHIVES.DBF.HKNWFZ
E:\ORCLNEW1\ZHSERVICES.DBF.HKNWFZ
E:\ORCLNEW1\ZHADVICES.DBF.HKNWFZ
E:\ORCLNEW1\ZHEXPENSES.DBF.HKNWFZ
E:\ORCLNEW1\ZHMEDICINE.DBF.HKNWFZ
E:\ORCLNEW1\ZHLAB.DBF.HKNWFZ
E:\ORCLNEW1\ZHCHECK.DBF.HKNWFZ
E:\ORCLNEW1\ZHLOB.DBF.HKNWFZ
E:\ORCLNEW1\ZHINDEX.DBF.HKNWFZ
E:\ORCLNEW1\SLREPORT.DBF.HKNWFZ
E:\ORCLNEW1\ZHMATERIAL.DBF.HKNWFZ
E:\ORCLNEW1\ZHMEDREC.DBF.HKNWFZ
E:\ORCLNEW1\ZHINSURE.DBF.HKNWFZ

由于该客户的数据库中有大量的xml列类型,导致exp无法导出,只能使用expdp进行导出,因为expdp在导出过程中会创建中间表,因此又对数据库进行一些修复,确定数据库能够正常写入对象,并且数据库导出成功
2


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