#df
Filesystem 512-blocks Free %Used Iused %Iused Mounted on
/dev/hd4 16384 5064 70% 1388 34% /
/dev/hd2 4030464 1998456 51% 15586 4% /usr
/dev/hd9var 16384 360 98% 196 10% /var
/dev/hd3 262144 249960 5% 237 1% /tmp
/dev/hd1 540672 523240 4% 42 1% /home
/dev/datalv 35454976 7932224 78% 7608 1% /dbback

谁能帮我分析一下，我的硬盘还有多大空间吗？
这种分区合理吗？

没什么合理不合理.
你自己算算不就知道了
512-blocks

为什么 / 这么小？

共有35454976/2k的空间，还剩7932224/2k,使用率78%。
还有，/usr目录一般不太会再增长，你现在的使用率为51％，太浪费了。
一般/var,/usr到85％左右是最优的。

df默认是以block显示大小的，可以用 df -k 来用K显示

根文件系统 /dev/hd4 划分的太小了，可能满足不了需求。
/dev/hd2 似乎有些太大了。

文件系统/dev/datalv (mount点是/dbback)总共大小是17.727G,还有78%可以使用，挺大的。用来做数据库备份，也将就吧。

根文件系统下不要放什么东西的话，也算的上合理。

写文件错误？ 
可能是权限问题，请确认！

如果是用oracle用户来备份数据的话，建议用root用户将整个文件系统/dbback的属主都给oracle用户。

1G多，还是2G ？
在IBM AIX下面2G是个很重要的数字！

有具体一些的出错信息吗，比如备份不下去时的出错内容是什么。

为什么在AIX下2G是一个特殊的数字?

    许多CPU和系统调用接口(API)使用32位的字（word）。这个32位就在许多系统上带来了限制。在许多情况下，标准文件操作的API使用32位有符号word来指定文件大小和在文件中的相对位置。有符号的32位word使用最高位为符号位，因此31位所能表示的最大值就是0x7FFFFFFF（+2147483647),比2GB小1。

    2GB或大于2GB的文件统称"大文件”.所以在32位环境中就会遇到许多问题。为了克服这些问题，现在的操作系统大多使用64位定义了新的系统调用。新版本的Oracle使用了这些接口但是在处理“大文件“时还是有许多问题是需要注意的。

    另一个比较特殊的数字是4GB,0xFFFFFFFF作为无符号字所能表示的最大值就是4294967295，比4GB少1。加1则造成低32位变为0x00000000和一个进位，在32位体系中这个进位会被丢掉，因此4GB是另一个可能会发生问题的数字。

    32位影响着oracle的许多方面。为了使用大文件，你需要：
1. 操作系统支持2GB+的文件或裸设备
2. 操作系统具有支持操作2GB+文件IO的API
3. oracle使用这些API

你说的写错误，有80%的原因是由于权限不够造成了，包括主文件夹的权限。

还有一种可能，是你的dbback还没有被业务数据库授权过，如果是这样的话，只要在smit里，把dbback的属组加到业务数据库的用户里头就可以了。

对于2G，这个对你来说没什么关系，因为如果你的备份文件超过了2G，系统会提示“备份文件超过了2G限制，是否要继续备份”，如果按“Y”继续备份的话，系统就会自动把备份文件分割成多个2G大小的小文件。

典型的2GB+时export错误：

. . exporting table BIGEXPORT
EXP-00015: error on row 10660 of table BIGEXPORT, 
column MYCOL, datatype 96
EXP-00002: error in writing to export file
EXP-00002: error in writing to export file
EXP-00000: Export terminated unsuccessfully

对于你的情况，很大的可能是由于操作系统资源的限制。

查看一下，系统有没有这方面的限制。

忘了是哪个命令了：
 ulimit -f 
 ulimit -a