-
加我微信
加我QQ
-
3D Cloud
asm mount asm恢复 bbed bootstrap$ dmp损坏 dul In Memory kccpb_sanity_check_2 kfed MySQL恢复 ORA-00312 ORA-00607 ORA-00704 ORA-01110 ORA-01555 ORA-01578 ORA-08103 ORA-600 2662 ORA-600 3020 ORA-600 4000 ORA-600 4193 ORA-600 4194 ORA-600 16703 ORA-600 kccpb_sanity_check_2 ORA-15042 ORACLE 12C oracle dul ORACLE PATCH oracle勒索 oracle勒索病毒 oracle异常恢复 Oracle 恢复 ORACLE恢复 ORACLE数据库恢复 oracle 比特币 OSD-04016 redo异常 YOUR FILES ARE ENCRYPTED _ALLOW_RESETLOGS_CORRUPTION 勒索恢复 数据库恢复 比特币 比特币 oracle 比特币加密 比特币勒索
文章分类
- Others (2)
- 中间件 (2)
- WebLogic (2)
- 操作系统 (85)
- 数据库 (1,278)
- DB2 (22)
- MySQL (55)
- Oracle (1,166)
- Data Guard (39)
- EXADATA (7)
- GoldenGate (19)
- ORA-xxxxx (145)
- ORACLE 12C (71)
- ORACLE 18C (6)
- ORACLE 19C (8)
- Oracle ASM (52)
- Oracle Bug (7)
- Oracle RAC (40)
- Oracle 安全 (6)
- Oracle 开发 (25)
- Oracle 监听 (25)
- Oracle备份恢复 (382)
- Oracle安装升级 (51)
- Oracle性能优化 (62)
- 专题索引 (5)
- 勒索恢复 (35)
- PostgreSQL (11)
- SQL Server (25)
- SQL Server恢复 (6)
- TimesTen (7)
- 达梦数据库 (2)
- 生活娱乐 (2)
- 至理名言 (11)
- 虚拟化 (2)
- VMware (2)
- 软件开发 (19)
- Asp.Net (9)
- JavaScript (12)
- PHP (2)
- 小工具 (2)
-
最近发表
- Oracle Recovery Tools恢复MISSING00000文件故障
- 重命名sys用户引起数据库启动报ORA-01092 ORA-00600 kokasgi1错误
- coincidenceleague加密数据库恢复
- Oracle Recovery Tools—202008
- Oracle恢复小工具—Oracle Recovery Tools
- Assistant: Download Reference for Oracle Database/GI PSU, SPU(CPU), Bundle Patches, Patchsets and Base Releases-202007
- win asm disk header 异常恢复
- [squadhack@email.tg].Devos加密数据库恢复
- 系统故障oracle数据库恢复
- .lockbit加密数据库恢复
- 又一例oracle数据文件被加密恢复
- asm磁盘dd破坏恢复
- 12.2数据库启动报ORA-07445 lmebucp错误
- 又一起mysql rm删除数据库目录事故
- .SATANA加密数据文件恢复
- .KEYnnnn勒索病毒恢复
- ORA-21779错误处理
- mysql ibd文件被加密恢复
- 无法启动此程序，因为计算机中丢失api-ms-win-crt-runtime-l1-1-0.dll
- .ncov加密oracle数据库恢复
友情链接
分类目录归档：Linux
Using mlock ulimits for SHM_HUGETLB is deprecated
Oracle 数据库运行在linux 6中,启用大页之后,我们经常在/var/log/messages里面会看到类似这样的记录:Mar 11 12:12:33 i-q2ghx82t kernel: oracle (3677): Using mlock ulimits for SHM_HUGETLB is deprecated,我这里的环境也有重现该问题
环境说明
--系统配置 [root@i-q2ghx82t ~]# more /etc/issue CentOS release 6.8 (Final) Kernel \r on an \m [root@i-q2ghx82t ~]# ulimit -a core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 128331 max locked memory (kbytes, -l) 64 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 128331 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited [oracle@i-q2ghx82t ~]$ cat /proc/meminfo|grep Hu AnonHugePages: 0 kB HugePages_Total: 10752 HugePages_Free: 10752 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB [root@i-q2ghx82t ~]# more /proc/sys/vm/hugetlb_shm_group 0 [root@i-q2ghx82t ~]# id oracle uid=1000(oracle) gid=1000(oinstall) groups=1000(oinstall),1001(dba),1002(oper),1005(asmdba) --数据库参数 use_large_pages=only
在本环境中数据库启动正常,大页也可以正常使用,但是在系统日志中有类似Mar 11 12:12:33 i-q2ghx82t kernel: oracle (3677): Using mlock ulimits for SHM_HUGETLB is deprecated 这样的告警.通过分析,是由于少配置了hugetlb_shm_group参数导致(vm.hugetlb_shm_group 参数设置为有权使用 HugePages 的操作系统组。默认情况下，此参数设置为 0，从而允许所有组使用 HugePages。可以将此参数设置为 Oracle 数据库进程所属的操作系统组，如 oinstall),在本系统中在sysctl.conf中增加vm.hugetlb_shm_group=1000,然后重启系统(测试中,如果只是重启数据库,非系统重启后第一次重启数据库,不会出现该告警),系统日志没有出现相关告警.
在Linux 6中配置大页建议加上对应的hugetlb_shm_group参数
redhat和oracle linux kernel对应关系
|
Red Hat Enterprise Linux Version / Update |
Red Hat Enterprise Linux – Kernel version / redhat-release string |
Oracle Linux – Kernel version / release strings |
|
Red Hat Enterprise Linux 7 |
|
|
|
Red Hat Enterprise Linux 7 Update 6 |
3.10.0-957.el7.x86_64 |
4.14.35-1818.3.3.el7uek.x86_64 ^ * (x86_64 only) |
|
Red Hat Enterprise Linux 7 Update 5 |
3.10.0-862.el7.x86_64 |
4.1.12-112.16.4.el7uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux 7 Update 4 |
3.10.0-693.el7.x86_64 |
4.1.12-94.3.9.el7uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux 7 Update 3 |
3.10.0-514.el7.x86_64 |
4.1.12-61.1.18.el7uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux 7 Update 2 |
3.10.0-327.el7.x86_64 |
3.8.13-98.6.1.el7uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux 7 Update 1 |
3.10.0-229.el7.x86_64 |
3.8.13-55.1.6.el7uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux 7 GA |
3.10.0-123.el7.x86_64 |
3.8.13-35.3.1.el7uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux 6 |
|
|
|
Red Hat Enterprise Linux Server 6 Update 10 |
2.6.32-754.el6 |
4.1.12-124.16.4.el6uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux Server 6 Update 9 |
2.6.32-696.el6 |
4.1.12-61.1.28.el6uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux Server 6 Update 8 |
2.6.32-642.el6 |
4.1.12-37.3.1.el6uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux Server 6 Update 7 |
2.6.32-573.el6 |
3.8.13-68.3.4.el6uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux Server 6 Update 6 |
2.6.32-504.el6 |
3.8.13-44.1.1.el6uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux Server 6 Update 5 |
2.6.32-431.el6 |
3.8.13-16.121.el6uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux Server 6 Update 4 |
2.6.32-358.el6 |
2.6.39-400.17.1.el6uek ^ * |
|
Red Hat Enterprise Linux Server 6 Update 3 |
2.6.32-279.el6 |
2.6.39-200.24.1.el6uek ^ * |
|
Red Hat Enterprise Linux Server 6 Update 2 |
2.6.32-220.el6 |
2.6.32-100.34.1.el6uek ^ * |
|
Red Hat Enterprise Linux Server 6 Update 1 |
2.6.32-131.el6 |
2.6.32-100.34.1.el6uek ^ * |
|
Red Hat Enterprise Linux Server 6 GA |
2.6.32-71.el6 |
2.6.32-100.28.5.el6uek ^ * |
|
Red Hat Enterprise Linux 5 |
|
|
|
Red Hat Enterprise Linux Server 5 Update 11 |
2.6.18-398.el5 |
2.6.39-400.215.10.el5uek ^ * (x86, x86_64) |
|
Red Hat Enterprise Linux Server 5 Update 10 |
2.6.18-371.el5
|
2.6.39-400.209.1.el5uek ^ * (x86, x86_64) |
|
Red Hat Enterprise Linux Server 5 Update 9 |
2.6.18-348.el5 |
2.6.39-300.26.1.el5uek ^ * (x86, x86_64) |
|
Red Hat Enterprise Linux Server 5 Update 8 |
2.6.18-308.el5 |
2.6.32-300.10.1.el5uek ^ * (x86, x86_64) |
|
Red Hat Enterprise Linux Server 5 Update 7 |
2.6.18-274.el5 |
2.6.32-200.13.1.el5uek ^ * (x86, x86_64) |
|
Red Hat Enterprise Linux Server 5 Update 6 |
2.6.18-238.el5 |
2.6.32-100.26.2.el5uek ^ * (x86_64 only) |
|
Red Hat Enterprise Linux Server 5 Update 5 |
2.6.18-194.el5 |
2.6.18-194.el5 ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux Server 5 Update 4 |
2.6.18-164.el5 |
2.6.18-164.el5 ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux Server 5 Update 3 |
2.6.18-128.el5 |
2.6.18-128.el5 ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux Server 5 Update 2 |
2.6.18-92.el5 |
2.6.18-92.el5 ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux Server 5 Update 1 |
2.6.18-53.el5 |
2.6.18-53.el5 ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux Server 5 GA |
2.6.18-8.el5 |
2.6.18-8.el5 ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux 4 |
|
|
|
Red Hat Enterprise Linux 4 Update 9 |
2.6.9-100.EL |
2.6.9-100.0.0.0.1.EL ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux 4 Update 8 |
2.6.9-89.EL |
2.6.9-89.0.0.0.1.EL ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux 4 Update 7 |
2.6.9-78.EL |
2.6.9-78.0.0.0.1.EL ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux 4 Update 6 |
2.6.9-67.EL |
2.6.9-67.0.0.0.1.EL ^ * (x86, x86_64, ia64) |
|
Red Hat Enterprise Linux 4 Update 5 |
2.6.9-55.EL |
2.6.9-55.0.0.0.2.EL ^ * (x86, x86_64) |
|
Red Hat Enterprise Linux 4 Update 4 |
2.6.9-42.EL |
2.6.9-42.0.0.0.1.EL ^ * (x86, x86_64) |
|
Red Hat Enterprise Linux 4 Update 3 |
2.6.9-34.EL |
No corresponding version |
|
Red Hat Enterprise Linux 4 Update 2 |
2.6.9-22.EL |
No corresponding version |
|
Red Hat Enterprise Linux 4 Update 1 |
2.6.9-11.EL |
No corresponding version |
|
Red Hat Enterprise Linux 4 GA |
2.6.9-5.EL |
No corresponding version |
参考：Comparison of Red Hat and Oracle Linux kernel versions and release strings (文档 ID 560992.1)
mount: wrong fs type, bad option, bad superblock恢复Oracle
有朋友找到我们,说对lv进行收缩操作之后,导致文件系统无法mount,提示超级块损坏.
尝试mount失败
[root@GZGSDB data]# mount /dev/vg_gzgsdb/lv_home /home
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg_gzgsdb-lv_home,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
系统日志报错
Aug 16 21:23:24 GZGSDB kernel: EXT4-fs (dm-5): ext4_check_descriptors: Block bitmap for group 1 not in group (block 0)! Aug 16 21:23:24 GZGSDB kernel: EXT4-fs (dm-5): group descriptors corrupted!
主要操作
这里可以看出来，明显操作错误，在没有收缩文件系统之前，直接收缩的lv.
这里可以看出来，在发生故障之后，又做了很多操作，包括fsck和testdisk等,最终无法恢复,请求我们协助处理。
找出来备份超级块
[root@GZGSDB dul]# dumpe2fs /dev/vg_gzgsdb/lv_home |grep superblock dumpe2fs 1.41.12 (17-May-2010) ext2fs_read_bb_inode: A block group is missing an inode table Primary superblock at 0, Group descriptors at 1-52 Backup superblock at 32768, Group descriptors at 32769-32820 Backup superblock at 98304, Group descriptors at 98305-98356 Backup superblock at 163840, Group descriptors at 163841-163892 Backup superblock at 229376, Group descriptors at 229377-229428 Backup superblock at 294912, Group descriptors at 294913-294964 Backup superblock at 819200, Group descriptors at 819201-819252 Backup superblock at 884736, Group descriptors at 884737-884788 Backup superblock at 1605632, Group descriptors at 1605633-1605684 Backup superblock at 2654208, Group descriptors at 2654209-2654260 Backup superblock at 4096000, Group descriptors at 4096001-4096052 Backup superblock at 7962624, Group descriptors at 7962625-7962676 Backup superblock at 11239424, Group descriptors at 11239425-11239476 Backup superblock at 20480000, Group descriptors at 20480001-20480052 Backup superblock at 23887872, Group descriptors at 23887873-23887924 Backup superblock at 71663616, Group descriptors at 71663617-71663668 Backup superblock at 78675968, Group descriptors at 78675969-78676020 Backup superblock at 102400000, Group descriptors at 102400001-102400052 Backup superblock at 214990848, Group descriptors at 214990849-214990900
使用fsck修复
[root@GZGSDB data]# fsck -y /dev/vg_gzgsdb/lv_home
fsck from util-linux-ng 2.17.2
e2fsck 1.41.12 (17-May-2010)
fsck.ext4: Group descriptors look bad... trying backup blocks...
fsck.ext4: The ext2 superblock is corrupt when using the backup blocks
fsck.ext4: going back to original superblock
fsck.ext4: Device or resource busy while trying to open /dev/mapper/vg_gzgsdb-lv_home
Filesystem mounted or opened exclusively by another program?
--指定超级块恢复
[root@GZGSDB data]# fsck -y -b 102400000 /dev/vg_gzgsdb/lv_home
…………
Illegal block #0 (1296647770) in inode 354315. CLEARED.
Illegal block #1 (1398362886) in inode 354315. CLEARED.
Illegal block #3 (453538936) in inode 354315. CLEARED.
Illegal block #5 (808333361) in inode 354315. CLEARED.
Illegal block #6 (775434798) in inode 354315. CLEARED.
Illegal block #8 (1180306180) in inode 354315. CLEARED.
Illegal block #9 (1413893971) in inode 354315. CLEARED.
Illegal block #10 (1229347423) in inode 354315. CLEARED.
Illegal block #11 (1498613325) in inode 354315. CLEARED.
Illegal indirect block (1296389203) in inode 354315. CLEARED.
Inode 354315 is too big. Truncate? yes
Block #1074301965 (69632) causes directory to be too big. CLEARED.
Warning... fsck.ext4 for device /dev/mapper/vg_gzgsdb-lv_home exited with signal 11.
[root@GZGSDB data]# mount /dev/vg_gzgsdb/lv_home /home
mount: wrong fs type, bad option, bad superblock on /dev/mapper/vg_gzgsdb-lv_home,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so
至此基本上可以判断,直接修复该文件系统,让其正常mount的概率很小.直接通过lun层面来恢复.
通过工具解析lun
比较明显,客户经过一系列操作现在的现象是lv 1.03T,文件系统只有821G,明显和客户给我反馈的操作不符(应该是lv 821G),证明客户做了大量操作,已经导致文件系统损坏
由于文件系统严重异常,工具获取到的文件都是没有名称,直接从inode里面读取的数据.获取到这些数据之后,然后结合oracle的特性,判断出来对应的文件号关系(这里有大量文件重复);另外有个别文件通过inode恢复丢失,通过底层碎片重组进行恢复出来文件,然后恢复出来其中数据(asm disk header 彻底损坏恢复).这个客户比较幸运,system文件在另外一个分区中,不然工作量会大很多.
再次提醒:对lv操作一定要谨慎,特别是lvreduce操作,另外出现发生误操作之后,应该第一时间保护现场,而不是百度着去乱操作,可能导致故障更加悲剧