数据库发展到今天已经有半个世纪，这期间一代又一代产品涌现而出，越来越多的新特性如同雨后春笋。积累到今天，一个成熟的数据库产品，亮点特性可能用百计算也不为过。有些特性看上去朴实无华，往往成为了DBA最喜欢的，有的看上去十分有用，但是实际生产过程中，我却不敢用。盘点一下那些看上去很好，我却不敢用的特性。
特性一：自动主备切换
很多数据库都以这个作为宣传点，但是在我十年DBA生涯中，生产环境做主备切换的场景，有一次算一次，全部都是手动切换。
一方面是，公司对于数据库主备切换，有着严格的规章制度。尤其在金融行业，做一次切换都要主动上报监管，再写一份报告。如果谁在报告里把切换原因写成了自动切换，估计内部都不会通过，当天就会被合规部门请去喝茶谈天。一次主备切换，必须是由运维负责人和对应系统的负责人同时拍板才生效，DBA是没有权限自己做决定的。
另一方面，数据库支持自动主备切换，但是应用程序不一定支持。一个公司应用程序少则几十个，多则几百个，开发的公司水平不一，运维的熟悉程度有浅有深。光是数据库支持自动切换，应用程序不支持，那等于没有。即便是自动切换过去，谁也不敢保证平时一直不用的在被环境能够支撑起业务的必要需求和基本并发量。
自动主备切换，作为一个宣传点来宣传高可用的能力是可以的，但是如果作为一个公司生产环境尤其是重要的核心系统的时候，真正决定需要做主备切换的时候，往往是需要流程和决策的，自动显然不行。
特性二：存储自动扩展
很多数据库都带有这个功能，自动扩展表数据文件。我相信这个功能的本意是好的，让DBA不再过分关注文件使用量。但是实际生产中，我就职过的两家公司都有过规章制度，除非特殊需求或P0级别的系统例如财务，禁止开通自动扩展功能。多数时间里，只能监控文件或者表空间的使用量，到达一个阈值之后触发告警来决定是否扩展。
其实这和很多数据库服务器的使用情况是分不开的。一些甲方公司it预算有限，往往把一些非核心的系统按照表空间或者不同数据文件分隔，放到一个数据库实例中。最多的时候，我运维过一个数据库实例，上面跑了超过20个业务系统。这些非核心的业务系统写的怎么样就比较随缘了，有的业务逻辑有问题的，开了自增分分钟给你把存储空间干满。这时候如果恰好又有其他系统要自增的时候，对不起没空间了。这时候就得找存储管理员去要空间。新空间怎么找业务部门算费用，又是一个让人头疼的事。其实很多时候，都不是技术问题，还是钱和话语权的问题。
如果不自增，恰好某个业务系统出现数据量暴涨怎么办？通常会在系统上线之前告知是否能接受这种情况，如果业务方不能接受，那么请自己提预算买专用服务器，否则我们提供的标准服务就是这样。一开始把事情都定好，后续的很多问题都能把麻烦尽量减少。
特性三：闪回特性
闪回这个功能在实际生产中，我是不敢轻易用的，一方面会生成出更多的日志量增加存储开销，另一方面是闪回有可能造成一些无法预料的后果。
全库闪回往往拿来做一些非生产时段的用途，比如做系统升级或者灾备演练，这个时候全库闪回就是一个利器。但是生产时段全库闪回，谁都不敢保证，闪回到的时间点到底是不是那个时间点，两个时间点之间有哪些业务数据是实际需要但是又闪回没了的，也没有人会说的清楚。
单表闪回相对风险低一点，一个是范围有限，另一个是哪怕出了问题，补救的工作量也是可以评估的。然而不到万不得已，例如紧急且重要的业务需求，并且业务部门书面承诺自行承担所有风险，我是不敢使用。宁可找一台恢复机用备份+日志的方式，还原到某个指定的点。因为即便是单表，复杂的业务系统下，很可能有其他表需要读取关联数据，其影响面往往比我们想象的还要大。
