1.查找到系统程序崩溃时产生的core文件：
[root@rac1 ~]# find /u01 -name core.* -exec ls -lthr {} \
-rw------- 1 root root 480M Sep 27 12:01 /u01/oracle/product/crs/log/rac1/crsd/core.3907
core文件大小为480M，文件还挺大的。所以，平时，如果遇到磁盘空间不足的时候，没准就是core文件在做怪呢！
2.定位出是由于哪个文件产生的core文件：
[root@rac1 ~]# find /u01 -name core.* -exec ls -lthr {} \|awk '{print $9}'|xargs file/u01/oracle/product/crs/log/rac1/crsd/core.3907: ELF 32-bit LSB core file Intel 80386, version 1 (SYSV), SVR4-style, from 'crsd.bin'
由以下命令，可以看出core.3907的产生，是由于'crsd.bin'文件引起的。
3.使用gdb对core进行追踪：
[root@rac1 ~]# gdb /u01/oracle/product/crs/bin/crsd.bin /u01/oracle/product/crs/log/rac1/crsd/core.3907GNU gdb Fedora (6.8-37.el5)
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i386-redhat-linux-gnu"...
warning: Can't read pathname for load map: Input/output error.
warning: .dynamic section for "/lib/libdl.so.2" is not at the expected address
warning: difference appears to be caused by prelink, adjusting expectations
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libpthread.so.0...done.
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /u01/oracle/product/crs/lib/libocr10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocr10.so
Reading symbols from /u01/oracle/product/crs/lib/libocrb10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocrb10.so
Reading symbols from /u01/oracle/product/crs/lib/libocrutl10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libocrutl10.so
Reading symbols from /u01/oracle/product/crs/lib/libhasgen10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libhasgen10.so
Reading symbols from /u01/oracle/product/crs/lib/libclntsh.so.10.1...done.
Loaded symbols for /u01/oracle/product/crs/lib/libclntsh.so.10.1
Reading symbols from /u01/oracle/product/crs/lib/libskgxn2.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libskgxn2.so
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /usr/lib/libstdc++.so.5...done.
Loaded symbols for /usr/lib/libstdc++.so.5
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /u01/oracle/product/crs/lib/libnnz10.so...done.
Loaded symbols for /u01/oracle/product/crs/lib/libnnz10.so
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
Core was generated by `/u01/oracle/product/crs/bin/crsd.bin reboot'.
Program terminated with signal 6, Aborted.
[New process 4787]
[New process 4789]
[New process 4786]
[New process 4785]
[New process 4784]
[New process 4783]
[New process 4782]
[New process 4781]
[New process 4780]
[New process 4779]
[New process 4778]
[New process 4721]
[New process 4701]
[New process 4700]
[New process 4665]
[New process 4664]
[New process 4663]
[New process 4662]
[New process 4661]
[New process 4660]
[New process 4659]
[New process 4658]
[New process 4657]
[New process 4656]
[New process 4655]
[New process 4654]
[New process 4653]
[New process 4652]
[New process 4651]
[New process 4650]
[New process 4649]
[New process 4648]
[New process 4647]
[New process 4641]
[New process 4640]
[New process 4639]
[New process 4638]
[New process 4637]
[New process 4636]
[New process 4635]
[New process 4634]
[New process 4514]
[New process 3907]
#0 0x00389402 in __kernel_vsyscall ()
(gdb) where
#0 0x00389402 in __kernel_vsyscall ()
#1 0x009a1df0 in raise () from /lib/libc.so.6
#2 0x009a3701 in abort () from /lib/libc.so.6
#3 0x0099b26b in __assert_fail () from /lib/libc.so.6
#4 0x08363c8e in destr_detour5 () at clsThreadMain.cpp:70
#5 0x00af45ab in start_thread () from /lib/libpthread.so.0
#6 0x00a4acfe in clone () from /lib/libc.so.6
(gdb)
注意：上面的两行红色部分：
Core was generated by `/u01/oracle/product/crs/bin/crsd.bin reboot'.
Program terminated with signal 6, Aborted.
恰恰说明，由于系统发生reboot重启 *** 作，而产生了core文件。
oracle 产生core文件
xyk欠款3万以上还不上，12月14日最新逾期政策调整，联系我们
xyk网贷逾期处理
广告
Oracle Core- Essential Internals for DBAs and Developers 无水印pdf
25下载·0评论
2017年9月29日
oracle数据库原理基本知识点,ORACLE数据库基础知识1.doc
108阅读·0评论·0点赞
2021年5月7日
浅谈Core文件分析
6248阅读·0评论·0点赞
2014年7月23日
执行oracle命令时core,oracle coredump
135阅读·0评论·0点赞
2021年5月4日
oracle core文件使用率,Oracle EBS$INST_TOP/ora/10.1.2/forms存在很多core.*文件
165阅读·0评论·0点赞
2021年5月1日
不断有core文件在$ORACLE_HOME/dbs目录产生
3149阅读·0评论·0点赞
2014年1月21日
无锡xyk还不上了，不想连累家人，联系我们帮您
全国逾期处理中心
广告
oracle目录下core文件是什么,学习猿地-oracle core 概述
298阅读·0评论·0点赞
2021年5月2日
oracle core文件使用率,不断有core文件在$ORACLE_HOME/dbs目录产生
221阅读·0评论·0点赞
2021年4月3日
oracle目录下core文件是什么,oracle中adump,bdump,dpdump,udump目录中一些内容的作用
270阅读·0评论·0点赞
2021年5月2日
oracle 产生core文件,11.2.0.3 AIX RAC下$ORACLE_HOME/dbs生成大量core_* dump文件
181阅读·0评论·0点赞
2021年5月8日
linux core 调试 gdb,gdb core 调试_gdb coredump 调试_linux gdb core 调试(3)
159阅读·0评论·0点赞
2021年5月26日
软件测试解决Oracle问题,如何快速解决Oracle数据库中的常见问题
39阅读·0评论·0点赞
2021年5月4日
core文件截断的处理方法
4949阅读·0评论·0点赞
2012年2月10日
oracle设置core文件大小,Linux的Core文件设置与调试
488阅读·0评论·0点赞
2021年5月5日
oracle core文件使用率,oracle core dump 分析 - Oracle数据库管理 - Oracle数据库数据恢复、性能优化来问问AskMaclean - ParnassusDat...
190阅读·0评论·0点赞
2021年5月1日
GDB Core
651阅读·0评论·0点赞
2013年10月31日
Oracle core读书笔记
1735阅读·0评论·1点赞
2022年2月18日
oracle目录下core文件是什么,AIX上Oracle RAC 11g r2不断产生core文件问题的解决
98阅读·0评论·0点赞
2021年5月2日
Core文件产生以及调试
295阅读·0评论·0点赞
2021年9月24日
去首页
看看更多热门内容
因为磁盘阵列是将同一阵列的多个磁盘视为单一的虚拟磁盘(virtual disk),所以其数据是以分段(block or segment)的方式顺序存放在磁盘阵列中.
数据按需要分段,从第一个磁盘开始放,放到最后一个磁盘再回到第一个磁盘放起,直到数据分布完毕。至于分段的大小视系统而定,有的系统或以1KB最有效率,或以4KB,或以6KB,甚至是4MB或8MB的,但除非数据小于一个扇区(sector,即521bytes),否则其分段应是512byte的倍数。因为磁盘的读写是以一个扇区为单位,若数据小于512bytes,系统读取该扇区后,还要做组合或分组(视读或写而定)的动作,浪费时间。从上图我们可以看出,数据以分段于在不同的磁盘,整个阵列的各个磁盘可同时作读写,故数据分段使数据的存取有最好的效率,理论上本来读一个包含四个分段的数据所需要的时间约=(磁盘的access time+数据的tranfer time)X4次,现在只要一次就可以完成。
若以N表示磁盘的数目,R表示读取,W表示写入,S表示可使用空间,则数据分段的性能为:
R:N(可同时读取所有磁盘)
W:N(可同时写入所有磁盘)
S:N(可利用所有的磁盘,并有最佳的使用率)
Disk striping也称为RAID 0,很多人以为RAID 0没有甚么,其实这是非常错误的观念,因为RAID 0使磁盘的输出入有最高的效率。而磁盘阵列有更好效率的原因除数据分段外,它可以同时执行多个输出入的要求,因为阵列中的每一个磁盘都能独立动作,分段放在不同的磁盘,不同的磁盘可同时作读写,而且能在快取内存及磁盘作并行存取(parallel access)的动作,但只有硬件的磁盘阵列才有此性能表现。
从上面两点我们可以看出,disk spanning定义了RAID的基本形式,提供了一个便宜、灵活、高性能的系统结构,而disk striping解决了数据的存取效率和磁盘的利用率问题,RAID 1至RAID 5是在此基础上提供磁盘安全的方案。
RAID 1
RAID 1是使用磁盘镜像(disk mirroring)的技术。磁盘镜像应用在RAID 1之前就在很多系统中使用,它的方式是在工作磁盘(working disk)之外再加一额外的备份磁盘(backup disk),两个磁盘所储存的数据完全一样,数据写入工作磁盘的同时亦写入备份磁盘。磁盘镜像不见得就是RAID 1,如Novell Netware亦有提供磁盘镜像的功能,但并不表示Netware有了RAID 1的功能。一般磁盘镜像和RAID 1有二点最大的不同:
RAID 1无工作磁盘和备份磁盘之分,多个磁盘可同时动作而有重叠(overlaping)读取的功能,甚至不同的镜像磁盘可同时作写入的动作,这是一种最佳化的方式,称为负载平衡(load-balance)。例如有多个用户在同一时间要读取数据,系统能同时驱动互相镜像的磁盘,同时读取数据,以减轻系统的负载,黾覫/O的性能。
RAID 1的磁盘是以磁盘延伸的方式形成阵列,而数据是以数据分段的方式作储存,因而在读取时,它几乎和RAID 0有同样的性能。从RAID的结构就可以很清楚的看出RAID 1和一般磁盘镜像的不同。
磁盘0
A0
A2
A4
B1
磁盘1
A1
A3
B0
B2
磁盘0
A0
A2
A4
B1
磁盘1
A1
A3
B0
B2
下图为RAID 1,每一笔数据都储存两份:
从上图可以看出:
R:N(可同时读取所有磁盘)
W:N/2(同时写入磁盘数)
S:N/2(利用率)
读取数据时可用到所有的磁盘,充分发挥数据分段的优点写入数据时,因为有备份,所以要写入两个磁盘,其效率是N/2,磁盘空间的使用率也只有全部磁盘的一半。
很多人以为RAID 1要加一个额外的磁盘,形成浪费而不看好RAID 1,事实上磁盘越来越便宜,并不见得造成负担,况且RAID 1有最好的容错(fault tolerence)能力,其效率也是除RAID 0之外最好的。我们可视应用的不同,在同一磁盘阵列中使用不同的RAID level,如华艺科技公司的OAraid系列都可同一磁盘阵列中定义八个逻辑磁盘(logic disk),分别使用不同的RAID level,分为C:,D:及E:三个逻辑磁盘(或LUN0,LUN1,LUN2).
RAID 1完全做到了容错包括不停机(non-stop),当某一磁盘发生故障,可将此磁盘拆下来而不影向其他磁盘的 *** 作待新的磁盘换上去之后,系统即时做镜像,将数据重新复上去,RAID 1在容错及存取的性能上是所有RAID level之冠。
在磁盘阵列的技术上,从RAID 1到RAID 5,不停机的意思表示在工作时如发生磁盘故障,系统能持续工作而不停顿,仍然可作磁盘的存取,正常的读写数据而容错则表示即使磁盘故障,数据仍能保持完整,可让系统存取到正确的数据,而SCSI的磁盘阵列更可在工作中抽换磁盘,并可自动重建故障磁盘的数据。磁盘阵列之所以能做到容错及不停机,是因为它有冗余的磁盘空间可资利用,这也就是Redundant的意义。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）