解决一次RMAN迟迟不能开始备份的问题

今天真倒霉，一个数据的归档满了，备份归档又一直失败。
查看RMAN日志，发现是无法MOUNT磁带

刚好今天备份DMP，占用了2个驱动器，而且那台机器无法配置LANFREE。tsm server又是100M网卡，操
刚好另外一个库做全备，要备3天。。。
这2个操作占完了所有驱动器
刚好今天又在做数据处理，产生大量日志。。。
什么都磊到今天来。。。

先把今天做DMP备份的TSM进程给杀了，空2个驱动器出来，重新开始备份
等了半天，仍然不见备份开始，检查RMAN端正常，检查TSM，发现SESSION也正常
查看了下后台进程

tsm: TSM>q process

 Process     Process Description      Status                                          
  Number                             
--------     --------------------     -------------------------------------------------
  12,662     Space Reclamation        Volume Z12591L3 (storage pool ODS-DBBK), Moved  
                                       Files: 0, Moved Bytes: 0, Unreadable Files: 0, 
                                       Unreadable Bytes: 0. Current Physical File     
                                       (bytes): 34,079,210,561 Current input volume:  
                                       Z12591L3. Current output volume: 001090L3.     
  12,663     Space Reclamation        Volume A00011 (storage pool ORASTG), Moved Files:
                                       0, Moved Bytes: 0, Unreadable Files: 0,        
                                       Unreadable Bytes: 0. Current Physical File     
                                       (bytes): 4,720 Waiting for mount point in device
                                       class LTODEV (57 seconds).                     
  12,664     Space Reclamation        Volume A00016 (storage pool FSSTG), Moved Files:
                                       0, Moved Bytes: 0, Unreadable Files: 0,        
                                       Unreadable Bytes: 0. Current Physical File     
                                       (bytes): 2,147,737,399 Current input volume:   
                                       A00016.  
                                      
ODS-DBBK那个存储池竟然在做Space Reclamation
于是把Space Reclamation的进程给cancel掉
tsm: TSM>cancel process 12662
ANR0940I Cancel request accepted for process 12662.

尝试开始备份，但是其每完成一个备份片，就要重新做Space Reclamation

tsm: TSM>q stg ODS-DBBK f=d

               Storage Pool Name: ODS-DBBK
               Storage Pool Type: Primary
               Device Class Name: LTO3DEV
              Estimated Capacity: 95,637 G
                        Pct Util: 70.4
                        Pct Migr: 89.9
                     Pct Logical: 100.0
                    High Mig Pct: 90
                     Low Mig Pct: 70
                 Migration Delay: 0
              Migration Continue: Yes
             Migration Processes:
               Next Storage Pool:
            Reclaim Storage Pool:
          Maximum Size Threshold: No Limit
                          Access: Read/Write
                     Description:
               Overflow Location:
           Cache Migrated Files?:
                      Collocate?: No
           Reclamation Threshold: 40
 Maximum Scratch Volumes Allowed: 0
   Delay Period for Volume Reuse: 0 Day(s)
          Migration in Progress?: No
            Amount Migrated (MB): 0.00
Elapsed Migration Time (seconds): 0
        Reclamation in Progress?: Yes
 Volume Being Migrated/Reclaimed: Z12558L3
  Last Update by (administrator): ADMIN
           Last Update Date/Time: 12/12/08   15:39:17
        Storage Pool Data Format: Native
            Copy Storage Pool(s):
         Continue Copy on Error?:
                        CRC Data: No

回收的阀值是40

tsm: TSM>q vol stgpool=ODS-DBBK

看了下下还有空间能用

修改回收的阀值为100，暂时关闭回收

tsm: TSM>update stgpool ODS-DBBK reclaim=100
ANR2202I Storage pool ODS-DBBK updated.

备份正常，备份完成后修改会原阀值

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/8242091/viewspace-623246/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/8242091/viewspace-623246/