昨夜跟着IBM工程师一起搞了TSM磁带库，以前有一些TSM文档，但是总是看不下去。今天对这个东西算是有了点感悟，记录下来。

1 . 它其实就是一个独立于数据库的一个备份工具，虽然需要用到RMAN，但它只是需要RMAN的接口而已，记得以前学习数据库时听老师说RMAN就是个接口，有些不明白，今天总算明白了。
其实通俗讲就是TSM就是利用了RMAN，做了备份的工作。
2 .  即使数据库已经开始运行了很久，也是可以部署TSM的。它就是把数据备份到一个磁带库里。
3 .  TSM 跟RMAN的备份策略，毛关系都没有，用rman执行show all,里面有一些配置，比如说保留几天的数据什么的，跟TSM基本没有什么关系，其实也有点关系，举一个简单的例子，如果
rman里配置保留7天的数据，一般我们tsm备份策略都是通过脚本实现的，在脚本里备份归档后，都会有delete input之类的，删除归档，但是rman里的策略跟它是矛盾的，因为保留7天的数据，
意味着保留7填的归档。所以这时，TSM执行删除归档时，只会删除7天以前的归档，挺有意思的。
4 . 根据上面所说的，rman 跟TSM毛关系都没有，还想说一点，在RMAN show all里，有一个默认的备份路径，默认是DISK，注意，虽然TSM备份走的是磁带库，但是这里不用修改为sbt_tape，
真是没有关系，rman的备份脚本里第一行都会有一个配置信息，意思就是说，开放一个通道，走磁带库。所以，不用担心。
5 . 我们的配置策略挺有意思，用一个单独的数据库做rman备份时的资料档案库，所以在备份时，需要指定catalog rman/rman@catalog_database  刚开始做的时候,IBM 工程师没有指定，就
备份了，导致资料档案库都存在了rman里，后来又备份了一次，这次指定了，但报错，我想了想，建议他用crosscheck 然后删除一下。果然最后解决了。
6 . 还有一个故事，其实也是第3条的一个引申，3月份的时候我去无锡处理一个数据库事件，当时具体情况是这样：因为一次断电，sysaux表空间坏了，再次启动数据库的时候，数据库能起来，
但是sysaux表空间的状态是recover，因为sysaux挂掉导致log日志迅速增大。系统性能受到了影响。这个事已经发生了一个多礼拜了，我一看他们的RMAN备份策略是保留7天的数据，但是他们
有tsm备份。当时我简单用restore和recover 进行恢复，出现需要的归档已经找不到了，我和那个dba就以为rman的备份策略和TSM的备份策略是相通的，也就是说：数据超过了7天，已经找不
到了，但是后来连接到rman,catalog到磁带库的资料档案库，再次进行了restore和recover操作，restore操作进行了半个小时也没有反应，我还以为挂死了，就去吃饭了，寻思不管它了，结果1
小时后回来发现，竟然restore成功了，后来recover 的过程也很漫长，持续了大概2个小时。最后竟然恢复了，我当时不知道是怎么回事，因为备份策略也不是这样，那个dba也无奈了。当时我
俩都不解，今天算是明白了，TSM就是备份自己的，别人的规则我不管，它备份满了之后，会循环写，从最早的备份开始冲，至于什么时候写满，你还在自己算一下。
7 . 一个资料档案库可以存多个数据库的rman备份信息。
今天先写到这，再想起来再写......