系统垃圾的清理-培训课件

系统垃圾的清理
系统工程部
余广宏
§了解项目日常问题处理的流程方法
§学会由磁盘空间问题引发的故障问题的处理方法
发现问题
程序应用
提交客服跟踪
异常
1.能够清楚描述问题出现的症状
2.分析问题引发的根源（程序、网络、主机或数据库）
3.寻求解决问题的方法或思路
4.第三方软硬件问题？本地无法及时解决，寻求远程技术支持或经验集
在公司内网请访问：http://192.168.2.50:8080
在联通专网请访问：http://10.1.41.30:8080
在Internet网请访问：http://203.86.86.137:8080
5.咨询主机或网络服务台，寻求快速解决方案
§垃圾对象定义范畴
§UNIX系统垃圾对象处理方法
§ORACLE数据库垃圾对象处理方法§系统日常运行管理注意事项
§Q&A
§系统垃圾的定义
系统垃圾就是会占用系统资源，包括磁盘空间、CPU、内存等，阻碍系统应用的正常运行。

§系统垃圾有什么危害
1、垃圾文件会占用大量的磁盘空间，包括占用磁盘空间和i节点
2、会占用内存和CPU资源
3、影响系统性能，使得系统慢如蜗牛
§系统垃圾对象来源的分类OS Space Problem
T e m p f i l e Database
Small file
Log File Application
Process Crash file
发现系统目录空间问题导致故障，需要判定产生空间问题的分区和目录，根据目录规划判定可能产生问题的来源
表1 常见操作系统目录检查方法dmesg
df -k
LINUX df
-g SOLARIS
cat /var/adm/syslog/syslog.log
HP-UX
AIX
案例一Case ID：1324
现象描述：某直辖市C网网管项目/usr2目录使用率达到94％，现场删除了一些文件，但是还是92％，所以提交客服系统处理
解决方法：技术支持人员反馈通过du-sk* 找到占用大空间那个目录，然后去检查该目录，并将情况反馈给研发部门找程序中可以删除的目录文件。

现场反馈：通过研发部门的协助，找到可以删除的程序文件，空间下降，问题解决案例二Case ID：207
现象描述：某省C网管主机系统的/var目录空间不到3天达到95％，提交客服系统要求检查系统是否有异常
解决方法：跟踪人员发现，该问题主要是UNICOM用户运行的snmp2db进程所致，删除了mail日志信息后，发现该文件很快又会增长，最终和研发定位到原因是
crontab调用的时候命令有错误，然后产生mail，改正命令后就解决
在以上处理过程中我们发现，维护人员最基本的要求：
1、熟悉应用程序的的目录结构，特别是应用的运行log信息
2、能够分析定位空间异常增长的目录
3、需要良好的书写习惯，创建公共文件或私有文件最好能够分类，并提供易于理解的
文件名
案例三case id：2182
现象描述：某省C网采集服务器的目录到达100%无法写入文件
CDMA% df-k
文件系统千字节用了可用容量挂接在
/dev/md/dsk/d8 20174761 8691554 11281460 44% /
/dev/md/dsk/d10 10086988 1588753 8397366 16% /usr
/dev/dsk/c1t3d0s2 70592505 69792182 94398 100% /usr2
/dev/dsk/c1t2d0s2 70592505 43235476 26651104 62% /u01
但实际上，在/usr2下面执行du-sk* 发现实际并未使用如此多的空间
解决方法：技术支持人员给出解决方法，
用prstat命令检查进程发现如下信息：
CDMA% prstat
PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP
3771 unicom48M 43M cpu3 0 0 112:04.05 18% file2dbv2.pl/1
3780 unicom27M 22M cpu1 0 0 112:02.28 18% file2dbv2.pl/1
以上两个进程已经运行了112个小时，按照采集流程不可能这么久，说明已经挂死，把这两个进程杀掉：CDMA% kill -9 3771
CDMA% kill -9 3780
目录/usr2一会就降到了66%
CDMA% df-k
文件系统千字节用了可用容量挂接在
/dev/md/dsk/d8 20174761 8691584 11281430 44% /
/dev/md/dsk/d10 10086988 1588753 8397366 16% /usr
/dev/dsk/c1t3d0s2 70592505 46030194 23856386 66% /usr2
案例四参见客服经验集33
现象描述：数据库服务器ORACLE软件安装目录硬盘空间被迅速占满
处理思路：通过前面的表1的各平台检查方法，检查系统空间情况及日志，得到空间占满的信息通常oracle可能引起问题的几个目录：
$ORACLE_BASE/admin/ORACLE_SID
$ORACLE_HOME/network/log
某省传输网管项目bdf发现：
/dev/vg00/oracle 8404992 8238286 166706 100% /oracle
删除$ORACLE_BASE/admin/ORACLE_SID/udump文件夹下trace文件后空间空闲不明显，最后检查发现监听日志文件占用空间过大
$ ls-l
-rw-rw-rw- 1 oracle dba4961855945 4月22日13:29 listener.log
-rw-rw-r-- 1 oracle dba466944 4月14日15:46 sqlnet.log
$ cat /dev/null>listener.log
$ ls-l
-rw-rw-rw- 1 oracle dba1791 4月22日13:29 listener.log
-rw-rw-r-- 1 oracle dba466944 4月14日15:46 sqlnet.log
最终剩余空间为/dev/vg00/oracle 8404992 3392260 4864472 41% /oracle
§归档日志空间回收处理方法
项目中我们常遇见由于归档日志满，导致数据库挂起的问题。

可能通常我们的做法是直接到归档日志目录空间中执行rm操作删除归档日志目录，其实这种做法还是有不妥之处，因为ORACLE并不知道空间已经被释放，归档日志信息并未及时更新，正确的做法除了删除归档日志目录下文件外，还需要执行如下操作：
$rman target /
rman>crosscheck archivelog all;
rman>delete expired archivelog all;
这样才算真正的完成了归档日志空间的清空释放。

§检查归档设置：
SQL> archive log list;
Database log mode Archive Mode
Automatic archival Enabled
Archive destination /opt/oracle/oradata/conner/archive
Oldest online log sequence 148
Next log sequence to archive 151
current log sequence 151
§查看数据文件位置
SQL>select name from v$datafile;
§查看日志文件位置
SQL>select member from v$logfile;
§查看临时表空间存放位置
SQL>select file_name from dba_temp_files;
§管理数据文件需要注意
请谨慎运用rm操作在操作系统上直接删除废弃的文件，对于系统中不能确定的文件尽量保存，或请尽量按照流程请求支持，以免误操作造成不可恢复的数据丢失。

计划执行
P D
A
C
措施
检查
P：计划，设定日常作业巡检计划
D：实施：按计划逐步检查系统各项性能指标
C：确认（检查）：确认并检查实施的各项性能指标
A：措施：确认实际效果与计划差异，并根据需要采取措施，预防为主
§备份重于一切§慎用rm操作
thank you。