ORA-01122 ORA-01200故障处理

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

标题:ORA-01122 ORA-01200故障处理

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

由于某种原因客户的数据库启动报ORA-01122 ORA-01200错误
ORA-01200


让客户把system01.dbf文件发给我进行分析,发现system01.dbf文件大于32G(在8k的blocksize库中,默认情况system01.dbf文件不会超过32G),这个明显异常
system01.dbf

检测坏块情况发现4096000之后的block全部为全0块
20230704165111

通过bbed分析文件头记录文件大小
20230704165343

通过bbed修改合适的值,并且把文件截取到适当大小,提供system文件给客户,直接启动库成功,实现数据库完美恢复
20230704165533

通过设置文件头大小和截断合适大小实现本次数据库恢复,以前有过类似恢复:
bbed处理ORA-01200故障

RMAN-06214: Archivelog错误

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

标题:RMAN-06214: Archivelog错误

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

有一个客户他是linux到win环境dg,alert日志报清除fra中日志失败

un Jun 25 10:50:14 2023
Media Recovery Waiting for thread 1 sequence 196437 (in transit)
Sun Jun 25 10:50:26 2023
WARNING: Cannot delete Oracle managed file /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_28/o1_mf_1_192078_l74s4m2l_.arc
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\XFFwin\XFF\trace\XFF_rfs_1100.trc:
ORA-01265: 无法删除 ARCHIVED LOG /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_28/o1_mf_1_192078_l74s4m2l_.arc
ORA-27056: 无法删除文件
OSD-04029: 无法获取文件属性
O/S-Error: (OS 3) 系统找不到指定的路径。

尝试人工rman删除日志,报RMAN-06214错误

RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192575_l78zobv0_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192576_l791fo3j_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192577_l7935w3d_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192578_l794y5bc_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192579_l795cngq_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192580_l795con4_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192581_l795jtxk_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192582_l795k97z_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192583_l795noy1_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192584_l795vvjg_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192585_l796y9o2_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192586_l798pk99_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192587_l79bgx33_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192588_l79bm1wf_.arc
RMAN-06214: Archivelog      /u01/oracle/fast_recovery_area/XFFDG/archivelog/2023_05_29/o1_mf_1_192589_l79bm2tn_.arc

crosscheck报ORA-19633错

RMAN> CROSSCHECK ARCHIVELOG ALL;

释放的通道: ORA_DISK_1
释放的通道: ORA_DISK_2
释放的通道: ORA_DISK_3
释放的通道: ORA_DISK_4
分配的通道: ORA_DISK_1
通道 ORA_DISK_1: SID=1717 设备类型=DISK
分配的通道: ORA_DISK_2
通道 ORA_DISK_2: SID=13 设备类型=DISK
分配的通道: ORA_DISK_3
通道 ORA_DISK_3: SID=579 设备类型=DISK
分配的通道: ORA_DISK_4
通道 ORA_DISK_4: SID=1148 设备类型=DISK
对归档日志的验证成功
归档日志文件名=D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XFFWIN\ARCHIVELOG\2023_06_25\O1_MF_1_196451_L9HC90MS_.ARC REC
ID=35113 STAMP=1140433431
对归档日志的验证成功
归档日志文件名=D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\XFFWIN\ARCHIVELOG\2023_06_25\O1_MF_1_196452_L9HC9271_.ARC REC
ID=35112 STAMP=1140433425
已交叉检验的 2 对象

RMAN-00571: ===========================================================
RMAN-00569: =============== ERROR MESSAGE STACK FOLLOWS ===============
RMAN-00571: ===========================================================
RMAN-03009: crosscheck 命令 (ORA_DISK_4 通道上, 在 06/25/2023 11:04:30 上) 失败
ORA-19633: 控制文件记录 30322 与恢复目录不同步

常规方法无法删除归档日志,只能通过dbms包强制删除归档日志

C:\Users\Administrator>sqlplus / as sysdba

SQL*Plus: Release 11.2.0.4.0 Production on 星期日 6月 25 11:05:15 2023

Copyright (c) 1982, 2013, Oracle.  All rights reserved.


连接到:
Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> execute sys.dbms_backup_restore.resetCfileSection( 11);

PL/SQL 过程已成功完成。

asm磁盘加入vg恢复

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

标题:asm磁盘加入vg恢复

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

又一个客户把asm disk做成pv,加到vg中,并且对lv进行了扩展(ext4的文件系统)
asm-disk-pv


这个客户做了上述操作之后,没有对lv进行写入其他数据,所以破坏较少(主要的破坏就是ext4的每个一段就会置空一部分block预留给文件系统写入元数据使用),通过winhex查看被破坏磁盘发现lvm信息
lvm

对于这种情况,通过对文件头进行修复,结合工具直接拷贝出来数据文件(个别文件元数据损坏通过基于block的方式恢复dbf)
asm-dbf

然后直接恢复dbf中数据文件(对于异常的主要是segment header被置空的tab使用dul单独扫描处理),实现客户数据的最大限度恢复
以前类似文章:
asm disk被加入vg恢复
asm disk被分区,格式化为ext4恢复
pvcreate asm disk导致asm磁盘组异常恢复
再一起asm disk被格式化成ext3文件系统故障恢复
一次完美的asm disk被格式化ntfs恢复
oracle asm disk格式化恢复—格式化为ext4文件系统

ORA-600 kcbr_apply_change_11

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

标题:ORA-600 kcbr_apply_change_11

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

客户active dataguard应用日志报ORA-600 kcbr_apply_change_11错误

Sun Jun 25 10:31:25 2023
ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT  LOGFILE DISCONNECT FROM SESSION
Sun Jun 25 10:31:25 2023
MRP0 started with pid=32, OS id=6380 
 started logmerger process
Sun Jun 25 10:31:30 2023
Managed Standby Recovery starting Real Time Apply
Parallel Media Recovery started with 4 slaves
Waiting for all non-current ORLs to be archived...
All non-current ORLs have been archived.
Media Recovery Log D:\APP\ADMINISTRATOR\FAST_RECOVERY_AREA\xffWIN\ARCHIVELOG\2023_06_23\O1_MF_1_196319_L99NQQSN_.ARC
Sun Jun 25 10:31:31 2023
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr03_1540.trc  (incident=180300):
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\incident\incdir_180300\xff_pr03_1540_i180300.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Completed: ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT  LOGFILE DISCONNECT FROM SESSION
Sun Jun 25 10:31:32 2023
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr02_752.trc  (incident=180292):
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\incident\incdir_180292\xff_pr02_752_i180292.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_rfs_6032.trc:
ORA-01265: 无法删除 ARCHIVED LOG /u01/oracle/fast_recovery_area/xffDG/archivelog/2023_05_28/o1_mf_1_192064_l74rj3jz_.arc
ORA-27056: 无法删除文件
OSD-04029: 无法获取文件属性
O/S-Error: (OS 3) 系统找不到指定的路径。
Archived Log entry 35084 added for thread 1 sequence 196424 rlc 1013082900 ID 0xe513780f dest 3:
RFS[7]: Opened log for thread 1 sequence 196430 dbid -451738353 branch 1013082900
Slave exiting with ORA-600 exception
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr02_752.trc:
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Sun Jun 25 10:31:41 2023
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr04_3696.trc  (incident=180308):
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\incident\incdir_180308\xff_pr04_3696_i180308.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Sun Jun 25 10:31:41 2023
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_mrp0_6380.trc  (incident=180268):
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Incident details in: D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\incident\incdir_180268\xff_mrp0_6380_i180268.trc
Use ADRCI or Support Workbench to package the incident.
See Note 411.1 at My Oracle Support for error and packaging details.
Recovery Slave PR02 previously exited with exception 600
Sun Jun 25 10:31:41 2023
MRP0: Background Media Recovery terminated with error 448
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr00_7812.trc:
ORA-00448: 后台进程正常结束
Managed Standby Recovery not using Real Time Apply
Sun Jun 25 10:31:41 2023
Slave exiting with ORA-600 exception
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr03_1540.trc:
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Sun Jun 25 10:31:43 2023
Sweep [inc][180308]: completed
Sweep [inc][180300]: completed
Sweep [inc][180292]: completed
Sweep [inc][180268]: completed
Sweep [inc2][180300]: completed
Sweep [inc2][180292]: completed
Sweep [inc2][180268]: completed
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr04_3696.trc:
ORA-00448: 后台进程正常结束
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr04_3696.trc:
ORA-00339: 归档日志未包含任何重做
ORA-00334: 归档日志: 'D:\APP\ADMINISTRATOR\ORADATA\xff\REDO02.LOG'
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []
Slave exiting with ORA-600 exception
Errors in file D:\APP\ADMINISTRATOR\diag\rdbms\xffwin\xff\trace\xff_pr04_3696.trc:
ORA-00600: 内部错误代码, 参数: [kcbr_apply_change_11], [], [], [], [], [], [], [], [], [], [], []

通过分析可能为:Bug 31104809 – ORA-600: [kcbr_apply_change_11] during adg recovery (Doc ID 31104809.8)
官方WORKAROUND:
In ADG, mount the database (do not open it) and restart media recovery; once
the affected redo log sequence is applied, open the ADG in read only mode.

Oracle Recovery Tools恢复csc higher than block scn

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

标题:Oracle Recovery Tools恢复csc higher than block scn

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

有客户强制关闭数据库,结果有数据块报坏块,dbv检查为:csc higher than block scn问题
20230622151852


该问题主要是由于scn异常导致通过Oracle Recovery工具进行修复
20230622151609
20230622151620

dbv再次验证数据块ok,Oracle Recovery完美代替bbed解决该问题
20230622151915

通过OraRecovery工具快速解决csc higher than block scn故障
软件下载:OraRecovery下载
使用说明:使用说明

.mdf.locked加密sql server完美恢复

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

标题:.mdf.locked加密sql server完美恢复

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

有可能用友ERP软件的sql server 数据库所在机器被勒索病毒加密,扩展名为.locked和昨天恢复的基本类似(.locked加密勒索数据库级别恢复),通过分析确认sql server被这种病毒加密,也可以完美恢复
20230611201149


20230611204905

通过恢复之后数据库正常挂载成功
20230612000539

测试应用一切正常
20230611224838
对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。

.locked加密勒索数据库级别恢复

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

标题:.locked加密勒索数据库级别恢复

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

有客户数据库被加密成.locked结尾的扩展名,数据库无法正常使用
.locked


对应的READ_ME1.html文件中信息类似:
send 0.1btc to my address:bc1ql8an5slxutu3yjyu9rvhsfcpv29tsfhv3j9lr4. contact email:service@hellowinter.online,if you can’t contact my email, please contact some data recovery company(suggest taobao.com), may they can contact to me .your id: ATNtkQxKZ8uaTNt3etgDXVdN2MjvPC8XoWOpoc7l25Dyg5ePEA6AFtj0sE8rYUX+Jm+1ajXASCAREJO8GD+53eqiUX26/s2aTX4uTkaAY90xTg6UIQ1SqhPpylXRsY759aUnOPeHWuv8fwj03g7vN68ctgjiRgHz3h1gNoOEDzT0GLGbr9+X6G2oCx23kNyWj3m2IXPJtyY8XqRa0UI1zNyjwyNoE6qNu0ZufInCnHKVrAp95ngibtUSmc6z+vYl8ROQlsPqi9UfyO0P3Wk2k9pLxLKsej7cBl0qtYEfRTou1v0/Ca4y57o1Djpaieklk2Ne03gYGztrGtS77S/zVzrg5B3x64qVuYNzQH9+LtmPE+6RqJY06CSmYr5f3GN1kEBuhsnGlNWjVJjjWimEMJXYMqqAY8fwb5DYxC/XCYg6jbg85R4CTOeE9DfC6yoPpsG1yXpDilBIFhFiTjWj9t94g0TBHi11dNBz1Fr+0x6TpmgfA9d0L/yjZSOTr7hQ9CeMn2eWjkYZ2jIoSV7XlHyDCbPRPlCTOnOX3ZP9zgQ48tXgJWbkds8SATOzjJk3+ttl+JNN7jScNvs7MZX0oVSyXVDrAdCHpftY63riuDuyE7rVBjtkOPr5njKSpA6K9EBD+FnCwQDzja7z78kOKXA/ddFj79mznzcnbODE8qnxitzNdv9SuQkJU+qVoH+fSndDGkDDxNliZJypHdwKM3ooO2q7fayq1Iw0dEN3FHbqgY/m3drUqge3UV07VrV9ht+tUzozUPoVBZbKSgZuYK2FKlXhlxhV/PXlskNtx+YFi1T4yzqjcT0a8HE5huQQzehDPeKQTRRpU+u9aq4TAxotjcTS1sfe/qgRKYyq+qLHg9rfFCcr5NjJPDSpWLTlhB+hUTK/iZqjYBaEccJjyvi0i+/5bDqmGmqkFeyWToyqhwlk4hN1IGyOHJY7Jf6a1S6CogVb34ArTOPFk2gKD7o4vXbERUmhw5xiP9c6Zwir2ENBdDaCl5p9oh44jpeoJqptZR4Uu1k8eqQNtUuXqlU9xvjaxt+dgXMQaul65nmgxgMmLUHjSSXZhGNzyeVGkz2KrP97ZLqYCq29iYoUt9WTLAmFtj0F+l4uYTj58+7xHM1/oXIMEOt3RmFv183I/yDesJaoV11cpbQUp1KJZvRvbws6CcajMnaH3zHJ7FHg74=
通过自研的oracle勒索加密恢复工具快速恢复文件
oracle-btb-recovery-tools

实现数据库直接open成功,实现数据0丢失
20230610185254

对于类似这种被加密的勒索的数据文件,我们可以实现比较好的恢复效果,如果此类的数据库(oracle,mysql,sql server)等被加密,需要专业恢复技术支持,请联系我们:
电话/微信:17813235971    Q Q:107644445QQ咨询惜分飞    E-Mail:dba@xifenfei.com
系统安全防护措施建议:
1.多台机器,不要使用相同的账号和口令
2.登录口令要有足够的长度和复杂性,并定期更换登录口令
3.重要资料的共享文件夹应设置访问权限控制,并进行定期备份
4.定期检测系统和软件中的安全漏洞,及时打上补丁。
5.定期到服务器检查是否存在异常。
6.安装安全防护软件,并确保其正常运行。
7.从正规渠道下载安装软件。
8.对不熟悉的软件,如果已经被杀毒软件拦截查杀,不要添加信任继续运行。
9.保存良好的备份习惯,尽量做到每日备份,异地备份。

ORA-16038 ORA-00354故障处理

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

标题:ORA-16038 ORA-00354故障处理

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

遇到一个案例,数据库open报ORA-16038,ORA-00354等错误
ORA-16038-ORA-00354


查询该redo状态(使用Oracle数据库异常恢复检查脚本(Oracle Database Recovery Check)脚本收集),确认为inactive
20230524213907

由于inactive 状态的redo损坏,无法被arch进程归档导致数据库无法正常open,尝试强制clear联机日志
ORA-00393-ORA-00312

由于25号文件属于offline状态,导致联机日志无法正常被clear,报ORA-00393 ORA-00312等错误.通过试验重现该问题.

SQL> alter database datafile 5 offline;

Database altered.

--使用一些技巧让数据库无法归档

SQL> select group#,status,archived from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         1 INACTIVE         NO
         2 ACTIVE           NO
         3 CURRENT          NO

SQL> shutdown abort;
ORACLE instance shut down.
SQL> startup mount;
ORACLE instance started.

Total System Global Area  626327552 bytes
Fixed Size                  2255832 bytes
Variable Size             234882088 bytes
Database Buffers          385875968 bytes
Redo Buffers                3313664 bytes
Database mounted.
SQL> alter database clear unarchived logfile group 1;
alter database clear unarchived logfile group 1
*
ERROR at line 1:
ORA-00393: log 1 of thread 1 is needed for recovery of offline datafiles
ORA-00312: online log 1 thread 1: '/u01/app/oracle/oradata/orcl/redo01.log'
ORA-01110: data file 5: '/u01/app/oracle/oradata/orcl/t_xifenfei01.dbf'

SQL> !oerr ora 393
00393, 00000, "log %s of thread %s is needed for recovery of offline datafiles"
// *Cause:  Log cannot be cleared because the redo in it is needed to recover
//          offline datafiles. It has not been archived so there is no
//          other copy available. If the log is cleared the tablespaces
//          containing the files will have to be dropped.
// *Action: Archive the log then repeat the clear command. If archiving is not
//          possible, and dropping the tablespaces is acceptible, then add the
//          clause UNRECOVERABLE DATAFILE at the end of the clear command.


SQL>  alter database clear unarchived logfile group 1 unrecoverable datafile;

Database altered.

SQL> select group#,status,archived from v$log;

    GROUP# STATUS           ARC
---------- ---------------- ---
         1 UNUSED           YES
         3 CURRENT          NO
         2 ACTIVE           NO

客户的问题也是通过unrecoverable datafile 方式强制clear联机日志成功,数据库open成功

unknown variable ‘default-character-set=utf8′ 处理

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

标题:unknown variable ‘default-character-set=utf8′ 处理

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

分享一例由于mysql参数配置不当,当时mysql无法正常启动的case

[root@XIFENFEI ~]# service mysql start
Redirecting to /bin/systemctl start mysql.service
Job for mysqld.service failed because the control process exited with error code. 
See "systemctl status mysqld.service" and "journalctl -xe" for details.
[root@XIFENFEI ~]# systemctl status mysqld.service
 mysqld.service - LSB: start and stop MySQL
   Loaded: loaded (/etc/rc.d/init.d/mysqld; bad; vendor preset: disabled)
   Active: failed (Result: exit-code) since Mon 2023-05-22 16:09:57 CST; 13s ago
     Docs: man:systemd-sysv-generator(8)
  Process: 101951 ExecStop=/etc/rc.d/init.d/mysqld stop (code=exited, status=0/SUCCESS)
  Process: 102545 ExecStart=/etc/rc.d/init.d/mysqld start (code=exited, status=1/FAILURE)

May 22 16:09:53 RHAA08-0901 systemd[1]: Starting LSB: start and stop MySQL...
May 22 16:09:57 RHAA08-0901 mysqld[102545]: Starting MySQL.... ERROR! 
            The server quit without updating PID file (/www/se....pid).
May 22 16:09:57 RHAA08-0901 systemd[1]: mysqld.service: control process exited, code=exited status=1
May 22 16:09:57 RHAA08-0901 systemd[1]: Failed to start LSB: start and stop MySQL.
May 22 16:09:57 RHAA08-0901 systemd[1]: Unit mysqld.service entered failed state.
May 22 16:09:57 RHAA08-0901 systemd[1]: mysqld.service failed.
Hint: Some lines were ellipsized, use -l to show in full.

mysql日志

2023-05-22T06:59:57.646266Z 0 [Warning] option 'max_allowed_packet': unsigned value 107374182400 adjusted to 1073741824
2023-05-22T06:59:57.646480Z 0 [Note] --secure-file-priv is set to NULL. 
          Operations related to importing and exporting data are disabled
2023-05-22T06:59:57.646548Z 0 [Note] /www/server/mysql/bin/mysqld (mysqld 5.7.41-log) starting as process 79451 ...
2023-05-22T06:59:57.726167Z 0 [Note] InnoDB: PUNCH HOLE support available
2023-05-22T06:59:57.726257Z 0 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2023-05-22T06:59:57.726269Z 0 [Note] InnoDB: Uses event mutexes
2023-05-22T06:59:57.726286Z 0 [Note] InnoDB: GCC builtin __atomic_thread_fence() is used for memory barrier
2023-05-22T06:59:57.726296Z 0 [Note] InnoDB: Compressed tables use zlib 1.2.12
2023-05-22T06:59:57.726306Z 0 [Note] InnoDB: Using Linux native AIO
2023-05-22T06:59:57.726975Z 0 [Note] InnoDB: Number of pools: 1
2023-05-22T06:59:57.727161Z 0 [Note] InnoDB: Using CPU crc32 instructions
2023-05-22T06:59:57.733999Z 0 [Note] InnoDB: Initializing buffer pool, total size = 4G, instances = 8, chunk size = 128M
2023-05-22T06:59:58.051369Z 0 [Note] InnoDB: Completed initialization of buffer pool
2023-05-22T06:59:58.087559Z 0 [Note] InnoDB: If the mysqld execution user is authorized,
 page cleaner thread priority can be changed. See the man page of setpriority().
2023-05-22T06:59:58.099727Z 0 [Note] InnoDB: Highest supported file format is Barracuda.
2023-05-22T06:59:58.202034Z 0 [Note] InnoDB: Creating shared tablespace for temporary tables
2023-05-22T06:59:58.202150Z 0 [Note] InnoDB: Setting file '/www/server/data/ibtmp1' size to 12 MB. 
Physically writing the file full; Please wait ...
2023-05-22T06:59:58.242233Z 0 [Note] InnoDB: File '/www/server/data/ibtmp1' size is now 12 MB.
2023-05-22T06:59:58.244128Z 0 [Note] InnoDB: 96 redo rollback segment(s) found. 96 redo rollback segment(s) are active.
2023-05-22T06:59:58.244163Z 0 [Note] InnoDB: 32 non-redo rollback segment(s) are active.
2023-05-22T06:59:58.244910Z 0 [Note] InnoDB: Waiting for purge to start
2023-05-22T06:59:58.295153Z 0 [Note] InnoDB: 5.7.41 started; log sequence number 1184000067
2023-05-22T06:59:58.295727Z 0 [Note] InnoDB: Loading buffer pool(s) from /www/server/data/ib_buffer_pool
2023-05-22T06:59:58.296135Z 0 [Note] Plugin 'FEDERATED' is disabled.
2023-05-22T06:59:58.296288Z 0 [Note] InnoDB: Buffer pool(s) load completed at 230522 14:59:58
2023-05-22T06:59:58.299095Z 0 [ERROR] unknown variable 'default-character-set=utf8'
2023-05-22T06:59:58.299131Z 0 [ERROR] Aborting

2023-05-22T06:59:58.299179Z 0 [Note] Binlog end
2023-05-22T06:59:58.299530Z 0 [Note] Shutting down plugin 'ngram'
2023-05-22T06:59:58.299560Z 0 [Note] Shutting down plugin 'partition'
2023-05-22T06:59:58.299572Z 0 [Note] Shutting down plugin 'BLACKHOLE'
2023-05-22T06:59:58.299588Z 0 [Note] Shutting down plugin 'ARCHIVE'
2023-05-22T06:59:58.299599Z 0 [Note] Shutting down plugin 'MyISAM'
2023-05-22T06:59:58.299626Z 0 [Note] Shutting down plugin 'MRG_MYISAM'
2023-05-22T06:59:58.299641Z 0 [Note] Shutting down plugin 'MEMORY'
2023-05-22T06:59:58.299657Z 0 [Note] Shutting down plugin 'PERFORMANCE_SCHEMA'
2023-05-22T06:59:58.299797Z 0 [Note] Shutting down plugin 'CSV'
2023-05-22T06:59:58.299811Z 0 [Note] Shutting down plugin 'INNODB_SYS_VIRTUAL'
2023-05-22T06:59:58.299822Z 0 [Note] Shutting down plugin 'INNODB_SYS_DATAFILES'
2023-05-22T06:59:58.299832Z 0 [Note] Shutting down plugin 'INNODB_SYS_TABLESPACES'
2023-05-22T06:59:58.299843Z 0 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN_COLS'
2023-05-22T06:59:58.299853Z 0 [Note] Shutting down plugin 'INNODB_SYS_FOREIGN'
2023-05-22T06:59:58.299863Z 0 [Note] Shutting down plugin 'INNODB_SYS_FIELDS'
2023-05-22T06:59:58.299873Z 0 [Note] Shutting down plugin 'INNODB_SYS_COLUMNS'
2023-05-22T06:59:58.299883Z 0 [Note] Shutting down plugin 'INNODB_SYS_INDEXES'
2023-05-22T06:59:58.299893Z 0 [Note] Shutting down plugin 'INNODB_SYS_TABLESTATS'
2023-05-22T06:59:58.299904Z 0 [Note] Shutting down plugin 'INNODB_SYS_TABLES'
2023-05-22T06:59:58.299914Z 0 [Note] Shutting down plugin 'INNODB_FT_INDEX_TABLE'
2023-05-22T06:59:58.299924Z 0 [Note] Shutting down plugin 'INNODB_FT_INDEX_CACHE'
2023-05-22T06:59:58.299934Z 0 [Note] Shutting down plugin 'INNODB_FT_CONFIG'
2023-05-22T06:59:58.299944Z 0 [Note] Shutting down plugin 'INNODB_FT_BEING_DELETED'
2023-05-22T06:59:58.299954Z 0 [Note] Shutting down plugin 'INNODB_FT_DELETED'
2023-05-22T06:59:58.299964Z 0 [Note] Shutting down plugin 'INNODB_FT_DEFAULT_STOPWORD'
2023-05-22T06:59:58.299974Z 0 [Note] Shutting down plugin 'INNODB_METRICS'
2023-05-22T06:59:58.299984Z 0 [Note] Shutting down plugin 'INNODB_TEMP_TABLE_INFO'
2023-05-22T06:59:58.299995Z 0 [Note] Shutting down plugin 'INNODB_BUFFER_POOL_STATS'
2023-05-22T06:59:58.300005Z 0 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE_LRU'
2023-05-22T06:59:58.300015Z 0 [Note] Shutting down plugin 'INNODB_BUFFER_PAGE'
2023-05-22T06:59:58.300025Z 0 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX_RESET'
2023-05-22T06:59:58.300035Z 0 [Note] Shutting down plugin 'INNODB_CMP_PER_INDEX'
2023-05-22T06:59:58.300045Z 0 [Note] Shutting down plugin 'INNODB_CMPMEM_RESET'
2023-05-22T06:59:58.300055Z 0 [Note] Shutting down plugin 'INNODB_CMPMEM'
2023-05-22T06:59:58.300066Z 0 [Note] Shutting down plugin 'INNODB_CMP_RESET'
2023-05-22T06:59:58.300075Z 0 [Note] Shutting down plugin 'INNODB_CMP'
2023-05-22T06:59:58.300085Z 0 [Note] Shutting down plugin 'INNODB_LOCK_WAITS'
2023-05-22T06:59:58.300095Z 0 [Note] Shutting down plugin 'INNODB_LOCKS'
2023-05-22T06:59:58.300105Z 0 [Note] Shutting down plugin 'INNODB_TRX'
2023-05-22T06:59:58.300116Z 0 [Note] Shutting down plugin 'InnoDB'
2023-05-22T06:59:58.300271Z 0 [Note] InnoDB: FTS optimize thread exiting.
2023-05-22T06:59:58.300437Z 0 [Note] InnoDB: Starting shutdown...
2023-05-22T06:59:58.400764Z 0 [Note] InnoDB: Dumping buffer pool(s) to /www/server/data/ib_buffer_pool
2023-05-22T06:59:58.401153Z 0 [Note] InnoDB: Buffer pool(s) dump completed at 230522 14:59:58
2023-05-22T07:00:00.340582Z 0 [Note] InnoDB: Shutdown completed; log sequence number 1184000086
2023-05-22T07:00:00.343128Z 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2023-05-22T07:00:00.343157Z 0 [Note] Shutting down plugin 'sha256_password'
2023-05-22T07:00:00.343165Z 0 [Note] Shutting down plugin 'mysql_native_password'
2023-05-22T07:00:00.343347Z 0 [Note] Shutting down plugin 'binlog'
2023-05-22T07:00:00.344547Z 0 [Note] /www/server/mysql/bin/mysqld: Shutdown complete

提示比较明显由于default-character-set=utf8参数设置不当当时,检查my.cnf配置,发现
在mysqld中配置了default-character-set=utf8,该参数正确配置为:character-set-server = utf8,设置正确参数值之后,mysql启动正常

[root@XIFENFEI data]# service mysql start
Redirecting to /bin/systemctl start mysql.service
[root@XIFENFEI data]# mysql -uroot -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 4
Server version: 5.7.41-log Source distribution

Copyright (c) 2000, 2023, Oracle and/or its affiliates.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| 365xxxy             |
| xxxxhu         |
| xxxiuye              |
| mysql              |
| performance_schema |
| xxxxchegn         |
| sxxxxp               |
| sys                |
| xxxxc               |
+--------------------+
10 rows in set (0.00 sec)

ORA-600 16703故障,客户找人恢复数据库,数据库被进一步恶意破坏—ORA-00704 ORA-00922

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

标题:ORA-600 16703故障,客户找人恢复数据库,数据库被进一步恶意破坏—ORA-00704 ORA-00922

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

有朋友找到我,数据库报ORA-600 16703错误,这个本来是一个比较常见的破坏故障(警告:互联网中有oracle介质被注入恶意程序导致—ORA-600 16703数据库启动报错如下:
ora-600-16703


修复tab$启动库报ORA-00704 ORA-00922错误

SQL> alter database Open;
alter database Open
*
第 1 行出现错误:
ORA-01092: ORACLE instance terminated. Disconnection forced
ORA-00704: bootstrap process failure
ORA-00922: missing or invalid option
进程 ID: 1340
会话 ID: 191 序列号: 3

ORA-704-ORA-922


ORA-00704 ORA-00922是比较少见的错误,第一感觉bootstrap$损坏了,对数据库启动过程进行跟踪

PARSING IN CURSOR #11700472 len=600 dep=1 uid=0 oct=1 lid=0 tim=338738406773 hv=4034608779 
ad='7ffdef83f360' sqlid='asgjp8bs7qgnb'
CREATE TABLE UNDO$("US#" 
END OF STMT
PARSE #11700472:c=0,e=361,p=0,cr=0,cu=0,mis=1,r=0,dep=1,og=4,plh=0,tim=338738406773
EXEC #11700472:c=0,e=73,p=0,cr=0,cu=0,mis=0,r=0,dep=1,og=4,plh=0,tim=338738406917
CLOSE #11700472:c=0,e=3,dep=1,type=0,tim=338738406997
=====================
PARSE ERROR #635423520:len=841 dep=1 uid=0 oct=1 lid=0 tim=338738407066 err=922
CREATE TABLE TS$<"TS#" NU ...
ORA-00704: 引导程序进程失败
ORA-00922: 选项缺失或无效
ORA-00704: 引导程序进程失败
ORA-00922: 选项缺失或无效

*** 2023-05-17 19:27:51.813
USER (ospid: 1340): terminating the instance due to error 704

*** 2023-05-17 19:27:54.050
EXEC #11710688:c=0,e=2481834,p=16,cr=62,cu=0,mis=0,r=0,dep=0,og=1,plh=0,tim=338740646732
ERROR #11710688:err=1092 tim=338740646777

进一步分析bootstrap$表记录
ts11


通过上述分析,可以确认原库的CREATE TABLE TS$(“TS#”被人修改为CREATE TABLE TS$<“TS#”,通过观察客户机器以及和客户确认,客户找的技术人员上传了bbed工具,并进行了一些操作.基于上述信息,大概率是被人通过bbed工具把TS$(修改为了TS$<,从而使得数据库修复tab$之后也无法正常启动.