标签云
asm恢复 bbed bootstrap$ dul kcbzib_kcrsds_1 kccpb_sanity_check_2 kcratr_nab_less_than_odr MySQL恢复 obet ORA-00312 ORA-00704 ORA-00742 ORA-01110 ORA-01200 ORA-01555 ORA-01578 ORA-01595 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-600 kcratr_nab_less_than_odr 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 比特币加密文章分类
- MongoDB (1)
- MongoDB恢复 (1)
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (112)
- 数据库 (1,879)
- DB2 (22)
- MySQL (82)
- Oracle (1,705)
- Data Guard (53)
- EXADATA (8)
- GoldenGate (24)
- ORA-xxxxx (168)
- ORACLE 12C (72)
- ORACLE 18C (6)
- ORACLE 19C (15)
- ORACLE 21C (3)
- Oracle 23ai (8)
- Oracle ASM (72)
- Oracle Bug (8)
- Oracle RAC (56)
- Oracle 安全 (6)
- Oracle 开发 (28)
- Oracle 监听 (29)
- Oracle备份恢复 (659)
- Oracle安装升级 (108)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (91)
- PostgreSQL (37)
- pdu工具 (7)
- PostgreSQL恢复 (13)
- SQL Server (34)
- SQL Server恢复 (14)
- TimesTen (7)
- 达梦数据库 (5)
- 达梦恢复 (3)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (51)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (34)
- MongoDB (1)
-
最近发表
- Oracle 19c 202610补丁(RUs+OJVM)-19.33
- 由于con$.con#值达到极限,触发数据库增加约束报ORA-600 12807错误
- MongoDB 离线提取工具—mongoext
- .bres勒索病毒加密数据库dmp文件可恢复
- ORA-600 krsm_mrp_rebuild_lf_list.lno_mismatch
- 记录一次0丢失的ORA-00354: 损坏重做日志块标头故障恢复
- 不当数据库恢复操作导致一个月数据丢失
- obet快速修复oracle 位图损坏块
- 不太常见的10.2.0.1的oracle redo损坏恢复
- obet forcecopy功能抢救硬件故障中的数据文件
- kcratr_nab_less_than_odr和system坏块故障处理
- 通过obet 恢复system坏块,打开数据库
- obet dbv功能完整说明
- 分享一例运行在aix上的sap系统数据库恢复过程
- OBET-Oracle Block Editor Tool使用说明
- 几乎动用了所有手段的Oracle故障恢复
- Oracle Block Edit Tool (obet) 功能增强–2026.07
- Oracle 19c 202607补丁(RUs+OJVM)-19.32
- Patch_SCN快速修复ORA-01555数据库open故障
- 快速处理 ORA-01210: data file header is media corrupt 故障
分类目录归档:Oracle
ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
客户反馈,rac有一个节点无法open(可以mount),在open过程报如下错误

alert日志内容中报错主要为:
ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
Thu Feb 29 17:46:15 2024
Successful mount of redo thread 1, with mount id 354054158
Database mounted in Shared Mode (CLUSTER_DATABASE=TRUE)
Lost write protection disabled
Completed: ALTER DATABASE MOUNT /* db agent *//* {1:32636:2} */
ALTER DATABASE OPEN /* db agent *//* {1:32636:2} */
Picked broadcast on commit scheme to generate SCNs
ARCH: STARTING ARCH PROCESSES
Thu Feb 29 17:46:16 2024
ARC0 started with pid=39, OS id=15401176
ARC0: Archival started
ARCH: STARTING ARCH PROCESSES COMPLETE
ARC0: STARTING ARCH PROCESSES
Thu Feb 29 17:46:18 2024
ARC1 started with pid=41, OS id=11993228
Thu Feb 29 17:46:18 2024
ARC2 started with pid=42, OS id=15007986
Thu Feb 29 17:46:18 2024
ARC3 started with pid=43, OS id=12779724
ARC1: Archival started
ARC2: Archival started
ARC1: Becoming the 'no FAL' ARCH
ARC1: Becoming the 'no SRL' ARCH
ARC2: Becoming the heartbeat ARCH
WARNING: The 'LOG_ARCHIVE_CONFIG' init.ora parameter settings
are inconsistent with another started instance. This may be
caused by the 'DB_UNIQUE_NAME' init.ora parameter being specified
differently on one or more of the other RAC instances; the
DB_UNIQUE_NAME parameter value MUST be identical for all
instances of the database.
Errors in file /oracle/oracle/diag/rdbms/xff/xff1/trace/xff1_lgwr_12976288.trc:
ORA-16188: LOG_ARCHIVE_CONFIG settings inconsistent with previously started instance
LGWR (ospid: 12976288): terminating the instance due to error 16188
Thu Feb 29 17:46:18 2024
System state dump requested by(instance=1, osid=12976288 (LGWR)),summary=[abnormal instance termination].
System State dumped to trace file /oracle/oracle/diag/rdbms/xff/xff1/trace/xff1_diag_13041806.trc
Thu Feb 29 17:46:18 2024
ORA-1092 : opitsk aborting process
Thu Feb 29 17:46:19 2024
License high water mark = 1
Instance terminated by LGWR, pid = 12976288
USER (ospid: 15532254): terminating the instance
Instance terminated by USER, pid = 15532254
检查LOG_ARCHIVE_CONFIG和DB_UNIQUE_NAME参数配置
SQL> select inst_id,value,name,length(value) from gv$parameter where name in ('log_archive_config','db_unique_name');
INST_ID VALUE NAME LENGTH(VALUE)
---------- ------------------------------ ------------------------------------- -------------
2 log_archive_config
2 xff db_unique_name 8
1 log_archive_config
1 xff db_unique_name 8
设置尝试log_archive_config配置为”和reset 均数据库无法正常启动
SQL> alter system set log_archive_config='' sid='*'; 系统已更改。 SQL> alter system reset log_archive_config scope=both sid='*'; 系统已更改。
设置log_archive_config=NODG_CONFIG数据库启动成功
SQL> alter system set log_archive_config=NODG_CONFIG scope=both sid='*'; 系统已更改。 SQL> alter database open; 数据库已更改。 SQL> exit 从 Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production With the Partitioning, Real Application Clusters, Automatic Storage Management, OLAP, Data Mining and Real Application Testing options 断开
.[hudsonL@cock.li].mkp勒索加密数据库完美恢复
有朋友oracle数据库所在机器被加密,扩展名为:.[hudsonL@cock.li].mkp,数据文件类似:

通过专业工具分析,确认这次运气非常好,每个文件就加密破坏前面31个block

通过研发的Oracle数据文件勒索恢复工具进行恢复

顺利数据库并且导出数据

mkp勒索病毒预防建议:
1. 教育和培训:提高用户的网络安全意识非常重要。通过定期的网络安全培训和教育,向用户传达有关勒索病毒及其传播方式的知识,让他们能够警惕潜在的威胁,并学会如何正确应对可疑的电子邮件、链接和附件。
2. 更新和维护:及时更新操作系统、应用程序和安全软件,以修补已知的漏洞,并确保系统能够及时获取最新的安全补丁。此外,定期进行系统维护和检查,确保系统的安全配置和设置。
3. 备份数据:定期备份重要的数据和文件,并将备份存储在安全的离线或云存储中。确保备份是完整的、可靠的,并且能够及时恢复,以便在发生勒索病毒感染或其他数据丢失事件时能够快速恢复数据。
4. 网络安全工具:使用可信赖的网络安全工具,包括防病毒软件、防火墙、入侵检测系统等,以提高系统的安全性和防护能力。定期对系统进行全面的安全扫描和检测,及时发现并清除潜在的威胁。
5. 访问控制:实施严格的访问控制措施,限制用户对系统和文件的访问权限,避免使用管理员权限进行日常操作,以减少恶意软件感染的风险。此外,定期审查和更新访问控制策略,确保系统安全性得到有效维护。
6. 应急响应计划:制定和实施应急响应计划,明确团队成员的责任和任务,建立应对勒索病毒和其他安全事件的应急响应流程,以最大程度地减少损失并快速恢复业务正常运营。
模拟带库实现rman远程备份
rman通过模拟带库备份到远程机器,需要先配置用户ssh到目标机器
linux平台oracle备份
RMAN> RUN {
2> ALLOCATE CHANNEL S1 DEVICE TYPE sbt
3> PARMS='SBT_LIBRARY=/tmp/rman_sync.so,ENV=(
4> OB_SERVER=www.xifenfei.com,
5> OB_USER=root,
6> OB_PORT=22123,
7> OB_PATH=/tmp)';
8> BACKUP CURRENT CONTROLFILE FORMAT 'ctl_%U';
9> }
allocated channel: S1
channel S1: SID=125 device type=SBT_TAPE
channel S1: SBT/SSH2-SFTP
Starting backup at 22-FEB-24
channel S1: starting full datafile backup set
channel S1: specifying datafile(s) in backup set
including current control file in backup set
channel S1: starting piece 1 at 22-FEB-24
channel S1: finished piece 1 at 22-FEB-24
piece handle=ctl_012jq4gg_1_1 tag=TAG20240222T190344 comment=API Version 2.0,MMS Version 1.0.9.0
channel S1: backup set complete, elapsed time: 00:00:25
Finished backup at 22-FEB-24
released channel: S1
RMAN> list backup;
List of Backup Sets
===================
BS Key Type LV Size Device Type Elapsed Time Completion Time
------- ---- -- ---------- ----------- ------------ ---------------
1 Full 9.50M SBT_TAPE 00:00:24 22-FEB-24
BP Key: 1 Status: AVAILABLE Compressed: NO Tag: TAG20240222T190344
Handle: ctl_012jq4gg_1_1 Media: 0B2B9255
Control File Included: Ckp SCN: 4438494 Ckp time: 22-FEB-24
win平台oracle备份
RMAN> RUN {
2> ALLOCATE CHANNEL S1 DEVICE TYPE sbt
3> PARMS='SBT_LIBRARY=D:\TEMP\rman_sync.dll,
4> ENV=(
5> OB_SERVER=www.xifenfei.com,
6> OB_USER=root,
7> OB_PORT=22123,
8> OB_PATH=/tmp/,
9> OB_PUBLIC_KEY=C:\Users\XIFENFEI\.ssh\id_rsa.pub,
10> OB_SECRET_KEY=C:\Users\XIFENFEI\.ssh\id_rsa,
11> OB_LOGFILE=d:\xifenfei.log)';
12> BACKUP CURRENT CONTROLFILE FORMAT 'ctl_%U';
13> }
分配的通道: S1
通道 S1: SID=156 设备类型=SBT_TAPE
通道S1: SBT/SSH2-SFTP
启动 backup 于 23-2月 -24
通道 S1: 正在启动全部数据文件备份集
通道 S1: 正在指定备份集内的数据文件
备份集内包括当前控制文件
通道 S1: 正在启动段 1 于 23-2月 -24
通道 S1: 已完成段 1 于 23-2月 -24
段句柄=ctl_012jt7mr_1_1 标记=TAG20240223T231642 注释=API Version 2.0,MMS Version 1.0.9.0
通道 S1: 备份集已完成, 经过时间:00:00:07
完成 backup 于 23-2月 -24
释放的通道: S1
RMAN> list backup;
备份集列表
===================
BS 关键字 类型 LV 大小 设备类型 经过时间 完成时间
------- ---- -- ---------- ----------- ------------ ----------
1 Full 9.50M SBT_TAPE 00:00:05 23-2月 -24
BP 关键字: 1 状态: AVAILABLE 已压缩: NO 标记: TAG20240223T231642
句柄: ctl_012jt7mr_1_1 介质: 0B2B9255
包括的控制文件: Ckp SCN: 14544437 Ckp 时间: 23-2月 -24

加我微信(17813235971)
加我QQ(107644445)

