记一次AIX平台存储脏块处理

客户数据库出现问题，归档日志不可读，具体表现为
[quote]$ du -sm /arch
du: /arch/1_418_722029122.dbf: 路径名中的文件或目录不存在。
du: /arch/1_419_722029122.dbf: 路径名中的文件或目录不存在。
du: /arch/1_41_722029122.dbf: 路径名中的文件或目录不存在。
du: /arch/1_420_722029122.dbf: 路径名中的文件或目录不存在。
du: /arch/1_421_722029122.dbf: 路径名中的文件或目录不存在。
du: /arch/1_422_722029122.dbf: 路径名中的文件或目录不存在。
du: /arch/1_423_722029122.dbf: 路径名中的文件或目录不存在。
du: /arch/1_424_722029122.dbf: 路径名中的文件或目录不存在
。。。[/quote]
[quote]$ ls -l
ls：0653-341 文件 ./1_418_722029122.dbf 不存在。
ls：0653-341 文件 ./1_419_722029122.dbf 不存在。
ls：0653-341 文件 ./1_41_722029122.dbf 不存在。
ls：0653-341 文件 ./1_420_722029122.dbf 不存在。
ls：0653-341 文件 ./1_421_722029122.dbf 不存在。
ls：0653-341 文件 ./1_422_722029122.dbf 不存在。
ls：0653-341 文件 ./1_423_722029122.dbf 不存在。
ls：0653-341 文件 ./1_424_722029122.dbf 不存在。
ls：0653-341 文件 ./1_425_722029122.dbf 不存在。
ls：0653-341 文件 ./1_426_722029122.dbf 不存在。
ls：0653-341 文件 ./1_427_722029122.dbf 不存在。
ls：0653-341 文件 ./1_428_722029122.dbf 不存在。
ls：0653-341 文件 ./1_429_722029122.dbf 不存在。[/quote]
但是ls命令可以读取文件名
[quote]$ ls
1_418_722029122.dbf 1_455_722029122.dbf 1_492_722029122.dbf 1_528_722029122.dbf 1_565_722029122.dbf
1_419_722029122.dbf 1_456_722029122.dbf 1_493_722029122.dbf 1_529_722029122.dbf 1_566_722029122.dbf
1_41_722029122.dbf 1_457_722029122.dbf 1_494_722029122.dbf 1_52_722029122.dbf 1_567_722029122.dbf
1_420_722029122.dbf 1_458_722029122.dbf 1_495_722029122.dbf 1_530_722029122.dbf 1_568_722029122.dbf[/quote]
后台alert日志显示，说明该存储可以写
[quote]Fri Aug 06 12:25:47 BEIST 2010
Thread 1 advanced to log sequence 4375 (LGWR switch)
Current log# 1 seq# 4375 mem# 0: /oradata/gshnc/redo01.log
Fri Aug 06 12:27:47 BEIST 2010
Thread 1 advanced to log sequence 4376 (LGWR switch)
Current log# 2 seq# 4376 mem# 0: /oradata/gshnc/redo02.log
Fri Aug 06 12:32:30 BEIST 2010
Thread 1 cannot allocate new log, sequence 4377
Private strand flush not complete
Current log# 2 seq# 4376 mem# 0: /oradata/gshnc/redo02.log
Fri Aug 06 12:32:31 BEIST 2010
Thread 1 advanced to log sequence 4377 (LGWR switch)
Current log# 3 seq# 4377 mem# 0: /oradata/gshnc/redo03.log[/quote]
并且刚切换的日志在存储上可见，注意：模糊匹配不可见
[quote][color=red]$ ls -l 1_4376*
ls：0653-341 文件 1_4376* 不存在。[/color]
$ ls -l /arch/1_4376_722029122.dbf
-rw-r----- 1 oracle dba 3896832 8月06 12时32 /arch/1_4376_722029122.dbf[/quote]

解决办法：
1、将数据库归档目录临时切换至另一目录
[quote]SQL> alter system set log_archive_dest_1='location=/backup/archlog';
System altered.[/quote]
2、通过fsck修复文件系统
[quote]p550data/>#umount /arch
umount: 0506-349 无法卸装 /dev/fslvapp：请求的资源繁忙。
p550data/>#fuser -c /arch
/arch: 1642702c
p550data/>#ps -ef|grep 1642702
root 1605816 889248 0 12时40分01秒 pts/0 0:00 grep 1642702
root 1642702 1638442 0 10时55分36秒 pts/3 0:00 -ksh
p550data/>#pwd
/
p550data/>#kill -9 1642702
p550data/>#umount /arch
p550data/>#fsck /dev/fslvapp


当前的卷是： /dev/fslvapp
主超块有效。
J2_LOGREDO:log redo processing for /dev/fslvapp
主超块有效。
索引节点 2 含有损坏的数据（2）。
无法修复索引节点 2; 发布？ y
根索引节点未分配。; 分配？ y
为根目录创建了初始化树。
超块被标记为“脏”，因为修复将要被写入。
*** 阶段 1 － 初始索引节点扫描
*** 阶段 2 － 处理剩余的目录
*** 阶段 3 － 处理剩余的文件
*** 阶段 4 － 检查和修复索引节点分配映射
文件系统索引节点映射已毁坏。; 修订？ y
*** 阶段 5 － 检查和修复块分配映射
块分配映射已毁坏。; 修订？ y
检测到未连接到根目录树
的索引节点。将重新连接。
文件系统是干净的。
超块标记为“脏”; 修订？ y
已经修复好所有观察到的不一致。[/quote]
再次执行fsck
[quote]p550data/>#fsck /dev/fslvapp


当前的卷是： /dev/fslvapp
主超块有效。
J2_LOGREDO:log redo processing for /dev/fslvapp
主超块有效。
*** 阶段 1 － 初始索引节点扫描
*** 阶段 2 － 处理剩余的目录
*** 阶段 3 － 处理剩余的文件
*** 阶段 4 － 检查和修复索引节点分配映射
*** 阶段 5 － 检查和修复块分配映射
文件系统是干净的。[/quote]
mount文件系统后发现，归档日志名字发生变化
[quote]p550data/>#cd /arch
p550data/arch>#ls
10 1015 106 114 122 130 139 147 155 23 31 4 48 56 64 72 80 89 97
100 1016 107 115 123 131 14 148 156 24 32 40 49 57 65 73 81 9 98
1009 1017 108 116 124 132 140 149 16 25 33 41 5 58 66 74 82 90 99
101 1018 109 117 125 133 141 15 17 26 34 42 50 59 67 75 83 91
1010 1019 11 118 126 134 142 150 18 27 35 43 51 6 68 76 84 92
1011 102 110 119 127 135 143 151 19 28 36 44 52 60 69 77 85 93
1012 103 111 12 128 136 144 152 20 29 37 45 53 61 7 78 86 94
1013 104 112 120 129 137 145 153 21 3 38 46 54 62 70 79 87 95
1014 105 113 121 13 138 146 154 22 30 39 47 55 63 71 8 88 96[/quote]
将其归档删除，立即发起一次数据库全备