一次oracle RAC数据库表空间调整的记录

原本以为就是几条命令的事，结果却弄的焦头烂额，究其原因还是一些命令的处理原理没有搞清楚，只知道那样用
而不知道跟它相关的重要信息，导致人为了试错，还好最后没有搞出妖娥子。

大概事情是这样的，我们的oracle RAC数据库需要调整表空间（使用裸设备），一个2TB的表空间需要缩小，然后
把释放出来的空间扩增到另外一个表空间，这个操作之前做过一个，命令也都整理保留了下来，这次就改了改
表空间名称。

第一步：
expdp \"sys/sys as sysdba\" DIRECTORY=dpump_dir dumpfile=20130203.dmp logfile=20130203_exp.log tablespaces=BAKDATA

生成的20130203.dmp文件大概800多GB

第二步：
drop tablespace BAKDATA INCLUDING CONTENTS;
执行这个的时候有报错，错误信息如下
ERROR at line 1:
ORA-00604: error occurred at recursive SQL level 1
ORA-01555: snapshot too old: rollback segment number 0 with name "SYSTEM" too
small

解决方法就是执行下面的命令
drop tablespace BAKDATA including contents and datafiles;

第三步:
rmlv -f users5_200g
之前的操作遇到过这个错误
0516-1008 rmlv: Logical volume users8_600g must be closed. If the logical volume
contains a filesystem, the umount command will close the LV device.
此时 ：
lsvg -l datavg --查看该lv state
lsvg -p datavg --查看该vg 的磁盘状态
因为数据库还是open 状态，所以即便是该表空间已经drop掉，但是有一些进程在使用这个lv
此时为了让 这个lv 处于 closed 状态就要重启 关闭database

不过，这次的删除lv操作没有遇到上面的问题，直接就删除成功了。

第四步:
mklv -y'users5_200g' -w'n' -s'n' -r'n' -t'raw' datavg 2400
chown oracle:dba /dev/rusers5_200g

重建lv并更改用户，用户组

第五步:
CREATE bigfile TABLESPACE BAKDATA DATAFILE '/dev/rusers5_200g' size 1199g;

最后：
impdp \"sys/sys as sysdba\" DIRECTORY=dpump_dir dumpfile=20130203.dmp logfile=20130203_imp.log tablespaces=BAKDATA


因为这一步需要的时间比较长，所以我就和LD一起出去逛街了，让它慢慢跑着吧
结果，收到短信、邮件报警，先是归档日志所在的文件系统利用率达到100% 然后RAC数据库的db1.srv
就OFFLINE了，于是立马回到电脑面前查原因，首先这个时候数据库没有任何写入操作，那么这么多归档日志
怎么生成出来的呢，在同事的配合下发现oracle imp命令也会产生归档日志（在数据库开启归档日志的前提下）
这个时候数据库的1级增量备份也从crontab里面启动起来了，系统的I/O也很大，有大量的读写产生（平常
这个时候应该不会有多少数据的，现在因为表空间也调整过，还有很多归档日志）

接下来我们首先在线扩大归档日志所在的文件系统，这个时候RAC数据库的db1.srv也自动ONLINE了，数据库
访问正常。
上面的imp导入进程也继续跑起来了，这里一个小插曲，我的Terminal因为太长是时间没有动，这个session
就被AIX系统自动断开了，不过imp进程并没有终止，我看了下它的父进程变成1了，看来被大BOSS接管了，
不过20130203_imp.log这个日志文件里面还是有更新的。
然后我们杀掉了rman的1级增量备份，等到imp进程成功结束后，把数据库之前的所有备份手动删除掉，再删除掉
所有归档日志，然后开始对数据库做0级全备，做完这些后，再把归档日志所在的文件系统缩小至之前的大小。

一切OK，貌似说有办法让已经开启归档日志的oracle数据库在做imp导入数据时不产生归档日志，这个等以后再整理吧！