HP_UX扩dump空间

有时宕机后发现dump空间不足,不能收集dump给RC分析,用以下方法扩dump空间.

1.先创建个连续的、坏块不转移的lvdump。

# lvcreate -L 4000 -n lvdump -C y -r n /dev/vg00

2.把下面这一行加到/etc/fstab,注意“/”后面是空格然后才是dump。

/dev/vg00/lvdump / dump defaults 0 0

3.激活dump区:

#crashconf -a

4.确认lvdump是否已经激活:

#crashconf     指定2级swap区为crash转储区

#crashconf -s

test_server[/]crashconf

Crash dump configuration has been changed since boot.

CLASS          PAGES  INCLUDED IN DUMP  DESCRIPTION

--------  ----------  ----------------  -------------------------------------

UNUSED         11339  no,  by default   unused pages

USERPG         15258  no,  by default   user process pages

BCACHE          5196  no,  by default   buffer cache pages

KCODE           2671  no,  by default   kernel code pages

USTACK           602  yes, by default   user process stacks

FSDATA             6  yes, by default   file system metadata

KDDATA         24595  yes, by default   kernel dynamic data

KSDATA          5869  yes, by default   kernel static data

Total pages on system:             65536

Total pages included in dump:      31072

DEVICE        OFFSET(kB)   SIZE (kB)  LOGICAL VOL.  NAME

------------  ----------  ----------  ------------  -------------------------

31:0x026000      310112      524288   64:0x000002  /dev/vg00/lvol2

31:0x026000     7498592     1048576   64:0x00000a  /dev/vg00/lvdump

----------

1572864

1.5线RC给的增加dump空间方法:

Adding more dump space for system

#lvlnboot -v|grep -i dump

#lvlnboot -d lvswap /dev/vg00

#lvlnboot -v|grep -i dump

时间: 2024-10-14 00:46:42

HP_UX扩dump空间的相关文章

基于Cordys C3版平台应用系统维护经验一则——Oracle数据库表空间满了

某日中午,有用户陆续反映系统问题,说流程送出异常.待办不消失.待办打不开等等.维护工程师开始分析问题,后台较为清晰的现象是流转日志记录插入数据失败,人工测试表插入成功,其它现象五花八门,没有规律,经过多位维护工程师的努力,终于由Oracle数据库管理工程师在16:01排除故障,系统基本恢复"正常". 故障原因是"应用系统Oracle数据库中Cordys用户所对应的表空间"满了,导致应用无法正常向数据库写入数据,造成业务数据不完整. 第二日,维护人员根据用户反馈,逐个

gparted在线扩分区大小

gparted在线扩分区空间(原数据不丢失) 应用场景: 如虚拟机上需要给linux系统增加分区,在vmware端增加大小后可在系统内通过gparted工具将原有分区大小扩容 # apt-get install gparted # gparted  (必须在图形界面) 右击分区--resize--将全部空间给它--Apply即可 验证: # fdisk -l # df -h # ls /home/

记一次UNDO表空间超90%的处理

今天在为一套库扩表空间时查看到UNDOTBS1/2使用率均超过了90%,监控居然没报警,呵呵,这种花钱买监控还不如Nagios SQL> select * from v$version; BANNER -------------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.4.0 - 64bit Pr

Oracle 数据库日常巡检

Oracle 数据库日常巡检 阅读目录 1. 检查数据库基本状况 2. 检查Oracle相关资源的使用情况 3. 检查Oracle数据库备份结果 4. 检查Oracle数据库性能 5. 检查数据库cpu.I/O.内存性能 6. 检查数据库安全性 7. 其他检查 回到顶部 1. 检查数据库基本状况 包含:检查Oracle实例状态,检查Oracle服务进程,检查Oracle监听进程,共三个部分. 1.1. 检查Oracle实例状态 select instance_name,host_name,sta

一张图让你学会LVM

导读 随着科技的进步,人们不知不觉的就进入了大数据的时代,数据的不断增加我们发现我们的磁盘越来越不够用了,接下来就是令人头疼的事情--加硬盘,数据的备份与还原.LVM就是Linux下专门针对我们数据的不断的扩大,在原有动态磁盘的基础上动态的调整磁盘的大小,LVM动态卷管理,一张图片让你深入了解lvm的使用. LVM——Logical Volume Manager LVM就是动态卷管理,可以将多个硬盘和硬盘分区做成一个逻辑卷,并把这个逻辑卷作为一个整体来统一管理,动态对分区进行扩缩空间大小,安全快

STM32/GD32上内存堆栈溢出探测研究

无数次遭受堆栈溢出折磨,随着系统变得复杂,故障点越来越难以查找!主要溢出情况如下:1,一般RAM最后两块空间是堆Heap和栈Stack,堆从下往上用,栈从上往下用,任意一个用完,都会进入对方的空间2,如果栈用完,进入堆的空间,这个时候系统是不会有任何异常的,也就是说,栈底没有什么意义.除非堆和栈指针重叠,否则大家相安无事,尽管栈用了堆的3,如果栈用完进入堆,并且还碰到了堆的空间,这个时候系统仍然没有异常,但是堆栈会相互修改数据.最悲剧的就是栈里面保存的然会地址lr,一旦被堆指针修改,返回的时候就

初识DSP

1.TI DSP的选型主要考虑处理速度.功耗.程序存储器和数据存储器的容量.片内的资源,如定时器的数量.I/O口数量.中断数量.DMA通道数等.DSP的主要供应商有TI,ADI,Motorola,Lucent和Zilog等,其中TI占有最大的市场份额.TI公司现在主推四大系列DSP1)C5000系列(定点.低功耗):C54X,C54XX,C55X 相比其它系列的主要特点是低功耗,所以最适合个人与便携式上网以及无线通信应用,如手机.PDA.GPS等应用.处理速度在80MIPS--400MIPS之间

设计实现OJ平台的遇到的一些问题和解决方法

需求 毕业设计,实现一个能够自动编译.运行.监测程序运行使用资源.恶意系统调用的监控的一个OJ平台. 在设计实现的过程中的想法.碰到的问题.求解的过程以及方法,在这里记录下来. 基础结构 OJ主要由前端系统(WEB)和后端的判题程序构成,想法是后端的裁判程序做通用点,减少和前端系统的耦合,所以把后端给分离出来成一个独立的程序,大概的结构图是这样的. 解释下: 1. 前端其实可以由任何流行的web语言来实现. 2. 这里的代理可有可无,代理在这里可以实现很多功能,比如负载均衡.数据库的业务逻辑等都

oracle 10g运维手册

1.    检查数据库基本状况... 4 1.1.     检查Oracle实例状态... 4 1.2.     检查Oracle服务进程... 4 1.3.     检查Oracle监听状态... 5 2.    检查系统和oracle日志文件... 6 2.1.     检查操作系统日志文件... 6 2.2.     检查oracle日志文件... 6 2.3.     检查Oracle核心转储目录... 7 2.4.     检查Root用户和Oracle用户的email. 7 3.