9、TSM存儲介質中存儲池和庫有什麼區別呢？
庫在TSM里的物理對應就是機械手
池是個邏輯概念，可以由不同的介質類型構成，比如文件、lto等等。可以通過設備類指定。
存儲池再和副本組中的dest參數關聯。對應到不同的策略域
這樣就形成閉環了。
10、使用TSM備份Oracle，怎麼設置通道會比較好？
通道數越多，對數據庫業務影響越大，對數據庫的並發讀性能要求越高，但如果通道數越多而通過單個通道內備份的data file越少、數據量越小，反而會降低備份效率。備份最終是要落入磁帶庫的，對於磁帶機而言，連續且大量的數據寫入效率是最高的。至於怎麼平衡，取決於備份管理員對這個系統數據庫和備份的理解了。
下面是ORACLE備份通道與消重效率的心得分享：
不管是哪一款備份軟件，對備份數據備份流程的控制尤其重要，特別是採用消重技術的備份。對備份數據的控制效用將直接影響消重性能。消重技術以變長、定長兩種為例，顧名思義變長是可以根據數據長度動態調整切片長度（如EMC DataDomain）,定長僅僅是以固定長度對數據進行切片。切片完成後，片（piece）的命中率直接決定消重性能。piece的命中率越高，消重越明顯。因此如何控制備份片（backup piece）單一度且相似度成為重點。
我們知道Oracle的Rman腳本里，有一個fileperset參數來控制每一個backup piece里會包含多少個data file。設想一下，如果fileperset越高，那每個backup piece就會包含更多的data file，backup piece的雜糅度就會越高（data file會被混亂隨機的組成一個backup piece，並不是每次都按照同一個順序擬成），那麼消重切片後piece的重複率必然低。綜合分析，一個合理的fileperset值將有效提升消重效率，fileperset越小越好，理論為1最好（如果沒有多路復用的情況，一個流會話會佔用一個備份設備）。
接下來關注備份通道數，Oracle的備份效率與數據結構類型、數據大小以及備份配置等息息相關。如何合理規劃備份通道數？關於此問題，我們需要了解一個概念——多路復用（multiplexing）。這個功能能夠讓多個oracle channel的備份流寫入一個磁帶機，如rman里分配了四個通道，但備份只有一個磁帶機在跑。對於單個磁帶機來講，連續、大量的數據流具有更高的寫入效率，如果單個backup piece數據量偏小就需要適當提高multiplexing的復用效率：允許x個會話同時寫入該設備（此操作提高數據雜糅度會降低後端消重效率）。對於Oracle而言，如果數據庫性能允許，更多的channel會帶來更高的數據讀取效率，備份速度越快。然而考慮到備份對業務的影響以及並發性能的限制，最佳的通道數需要多次調整嘗試。
除此之外若是oracle的消重備份，如果設置rman讀取datafile時的讀取塊大小以及備份軟件寫數據的塊大小以及設備消重的最小長度呈倍數關係，在消重效率和備份速率上都會有一定提升。
11、TSM備份和恢復在Oracle Rac下的具體操作是怎樣的？兩個節點都有問題的恢復嗎？
TSM for oracle的模塊所起的作用，簡單理解僅僅是提供了備份恢復的通道而已。所以在處理這個問題的時候先不要被tsm迷惑，僅從單純的oracle rman角度去考慮即可。
實踐上，rac環境的備份恢復僅在一個節點做就可以了，操作步驟基本上和單機環境沒什麼區別。
唯一需要考慮的一點就是rac環境下兩邊日誌是存儲在共享存儲還是兩邊各是個的，要確保備份恢復的動作可以同時獲取兩個節點的歸檔信息，其他就沒啥區別了。
12、TSM備份失敗可能的原因？如何處理？
備份軟件的日誌一般是第一手判斷問題的重點。多數成熟的備份軟件都會有詳細的日誌來說明相關的錯誤。
其次就是確認備份的環境、網絡、系統狀態、備份服務這些。
很多原因都會導致tsm備份失敗，查找原因需要看日誌——
查看一小時以前的所有日誌：
query actlog
如查看昨天8點以後的所有日誌
query actlog begindate=today-1 begintime=08:00:00
查看日誌中有關nc_ora節點的相關信息，可以加上search參數
query actlog search=nc_ora
查看TSM服務器中的日誌信息：
query actlog originator=server
數據庫：api的log，tsmserver的log
文件：ba的log，tsmserver的log
RC 106，一般是日誌權限的問題，找到需要的日誌，加上權限。
RC 12，介質mount不可用，一般是TSM調用帶庫的時候出現問題，查查驅動器和path，看看存儲池的最大可用scratch數值；如果是磁盤，看看磁盤的文件系統權限。
第一次啟動調度的時候，如果調度進程未啟動，可能是因為password生成參數沒設置好，或者沒有手動的登錄一下客戶端。
ANS0102W，語言包的問題導致dsmc登錄不了，將/opt/tivoli/tsm/client/lang/en_US目錄內所有內容，拷貝到/opt/tivoli/tsm/client/ba/bin目錄下試試。
ORA-19554，動態鏈接庫的問題可能大些。
如果日誌表述無法直接定位問題，那麼需要分析該問題是服務器端還是client端的問題，如果其他備份作業成功完成，那麼備份服務器基本判斷可用；之後看存儲池，發起測試備份寫入該存儲池，如果可行則存儲介質基本判斷可用，帶庫路徑驅動器路徑可用；如果是數據庫備份，則嘗試發起文件備份，如果文件備份成功，那麼基本判斷是該節點的數據庫備份問題，那麼可以嘗試重新執行配置，和檢查配置文件的方式，判斷問題。
13、TSM備份軟件實現數據級容災的實現方式是怎樣的？
數據容災，根本思想是關鍵的業務數據保留多份備份（本地和遠程）。 支持業務的基礎架構還有許多其他東東，物理機/虛擬機，虛擬機管理系統，存儲系統，實際的軟件/中間件/數據庫等。這些都好恢復，數據丟了就歇菜了！ 要想提高可用性，實現容災，提高RPO, RTO,也可以採用應用層方案，多活中心等，應用架構設計就考慮軟硬件故障，site故障等情形，但代價很高，更多的軟硬件，系統架構，運維更複雜等等，一般的企業不現實。 所以數據級容災就是以盡量小的代價獲得較高的收益！
TSM 大概可以有幾種方式：
雲備份池：
最新的7.1.6支持 複製數據到雲備份池（openstack, amazon, clearsafe), 複製到雲池的數據在線去重/壓縮。
磁帶拷貝池：
傳統方式，主池定期做備份到拷貝池(一般每天），拷貝池磁帶check out後運往本地或遠程災備中心。 相似的還可以採用export to tape, generate backupset to tape.
企業多站點，多個TSM Server的時候：
TSM server之間可以repl node/protect stg（6.3+以上server)，export to server將數據存在別的server中一份。
RPO/RTO 跟你使用的備份方式密切相關，比如採用磁帶拷貝池，晚上對主池備份一次，運到災備中心，RPO只能是恢復業務到一天前狀態。那我們採用雲備份池/TSM server之間可以repl node/protect stg，設定每天更頻繁的數據複製，則RPO是以小時計，整個業務系統可以恢復到幾個小時前的狀態。
RTO 則跟實際恢複數據時間（磁帶恢復速度）， 你的網絡帶寬（repl node方式，雲備份池），從災備中心運回磁帶的速度，恢復其他基礎架構的時間密切相關。
14、虛擬帶庫里有這樣一盤磁帶，在TSM下看是空的scratch狀態，在EMC控制台下看到是滿的？
1.查看帶庫日誌和備份軟件相關日誌信息；
2.TSM備份配置參數：
如果collocation的參數設置不是no。則可能的參數值包括：filespace，node，group。
如果設置為filespace，則磁帶選擇的順序是：
1． 優先選擇已經備份同一文件空間數據的磁帶；
2． 已經定義的空白磁帶；
3． 定義為scratch的空白磁帶；
4． 包含同一節點數據的已經使用過的磁帶；
5． 空間最大的一盤已經使用過的磁帶；
如果設置為node，則磁帶的選擇順序是：
1． 包含同一節點數據的已經使用過的磁帶；
2． 已經定義的空白磁帶；
3． 定義為scratch的空白磁帶；
4． 空間最大的一盤已經使用過的磁帶；
如果設置為group，則磁帶的選擇順序是：
1． 優先選擇已經包含來自客戶端所屬的collocation group的備份數據的磁帶；
2． 已經定義的空白磁帶；
3． 定義為scratch 的空白磁帶；
4． 空間最大的一盤已經是使用過的磁帶。
面對上述例子中情況，用戶可以考慮下列方法來跳過需要等待的60分鐘。
在checkout命令執行完後，修改磁帶A0000的access屬性為unavailable。命令如下：
update volume A0000 access=unavailable
15、備份VCener的解決方案
通過VMware VADP接口，將數據映射並和TSM API（TSM for VE）結合後，直接集中備份到備份設備中存放。
採用持續增量備份，就是TSM的永久增量備份技術，可以以最合理的方式減少備份窗口，冗餘數據和備份設備介質的資源使用率。
只有第一次是全備份（去掉了VM的空塊空間）。
後續備份，全部採用持續增量備份，自動啟動VMware的CBT（changed Block Tracking)功能，並跟蹤塊的變化進行僅增量備份。
16、TSM 怎樣實現歸檔SQLServer 2012 AlwaysON環境的數據庫的備份？
SQL Server2012中新增的AlwaysOn是一個新增高可用性解決方案。在AlwaysOn之前，SQL Server已經有的高可用性和數據恢復方案,比如數據庫鏡像，日誌傳送和故障轉移集群.都有其自身的局限性。而AlwaysOn作為微軟新推出的解決方案，提取了數據庫鏡像和故障轉移集群的優點。
因為always on 環境下，數據文件都到了 cluster節點對應的存儲池中。
現在我想到的另一個方法就是單獨通過SQL備份出文件，然後文件 歸檔到TSM
上面這種備份方式需要測試數據的完整性，確認數據是否可用。
17、如何保證TSM服務器端與客戶端的正常運行？
1，注意定期對tsm服務器和客戶端的巡檢，及時發現問題並處理。
2，定期檢查tsm備份是否成功，如果備份失敗查清原因並處理。
3，定期做好備份數據的恢復演練，保證tsm備份成功的數據是可用的。
4，配合自動化啟停腳本完成TSM系統的監控。
18、如何做到TSM系統的自動運維？
1，可以考慮使用crontab或調度完成備份，配合腳本完成日常檢查，比如郵件等功能，可以結合監控軟件如bmc或zabbix完成物理硬件和應用可用性監控，當然可以配合商業產品完成漂亮的圖表等查詢功能。
2，把TSM的運維做好的話，每天的人工巡檢是一部分工作之外，可以考慮投入一部分資金基於TSM平台進行一些開發，因為TSM有這樣的接口，比如調度執行結果，尤其是TSM調用腳本執行的結果，日誌在本地生成，可以考慮通過Agent採集的方式把日誌收集上來；比如數據量監測，每天的數據量都維持在一個平穩的數值，如果某一天數據量上來了，應該關注一下。應該有一些工作在做這方面的定製化。
19、為啥TSM對調度要「暫掛」
TSM如果對調度進行「立即運行」的時候，它會暫掛個好幾分鐘，為什麼要這麼久呢？沒什麼設計理由讓它等這麼久吧？
是從OC/AC 上提交的吧，這個從用戶角度是比較搞笑哈 ：）
實際TSM Scheduler的決定運行某個schedule的時候，是有一定的隨機性的，比如我們設定schedule的時候，大部分要設定一個啟動時間範圍，Server在這個時間範圍內啟動schedule就可以了。
從Server的角度考慮，在某個時刻，server可能面臨各種操作，比如客戶備份，恢複數據，expire inv, migration， reclamation. 還有一些內部damon做其他檢查，比如後台線程做tsm db index rerog等等， 如果在一個時間段設定了很多schedule, 先啟動那個，後啟動那個呢？ 為了避免衝突，server就盡量在符合設定的情況下， 按自己的節奏來啟動這些活動，就是有一定的隨機性。
20、TSM 經常會遇到物理帶庫里的部分或個別volume不能自動回收如何定位問題？
在tsm的使用過程中，經常會遇到部分或個別volume不能自動回收，比如說保留策略為一周，時常能夠發現個別好幾個月前的磁帶還在帶庫中，沒有被回收。其中裡邊的數據也均是老數據。1 ）遇到類似問題，應該如何操作和避免呢？ 2）有沒有什麼好的手段或機製做檢查，發生這個問題的原因又是什麼，如何定位問題 ？
- 如果你的帶子很多，存儲空間也夠，忽略這些問題好了。
想回收的話，檢查tape pool的回收閥值設置， 查看每個卷的可回收空間 pct_reclaim，
select volume_name,status,pct_reclaim from volumes where stgpool_name=’TAPE’ and pct_reclaim >= 0.0
or
http://www.thobias.org/tsm/sql/#toc120
然後可以降低RECLaim 的閥值，讓server回收這些磁帶。
update stg TAPE RECLAIMPRocess=4
RECLaim STGpool TAPE THreshold=10
或者用 命令 Move data vol_name 將這些磁帶里數據挪到別地，然後老帶子在REUsedelay天數過後就可以利用了。
- 應該是可回收空間 pct_reclaim 沒有達到回收閥值，或者回收就沒有有成功（查actlog，回收需要tape_pool里有額外的空白帶或空間）
檢查tape pool的回收閥值設置，mascr 設置以及 REUsedelay 的設置。 q content 查看是那些節點的數據，是否是新數據還存在這些帶子里？ 如果都是老數據沒有被expire inv過期，這個沒有詳細信息不好說，根據數據類型不同：歸檔數據，備份數據？ 先查查copygroup的各項設置吧。
以下文章點擊率最高
Loading…