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…