分级这个是必要的，因为整合要控制整体风险的影响范围，关于分类分级 各个行业公司都不同，业务系统按故障恢复时间点RTO、核心业务量/天、单笔平均资金量 等维度进行评估；管理系统按服务层级（公司级、业务条线级、部门级）、故障影响范围、连续性要求等维度进行评估 。根据等级...

1、应用要测试，要稍作修改。2、整合前的性能基线要分析，应对原有系统运行情况又足够的了解，对目标系统根据实际情况配置合适的硬件。

用linux自己带的RHCS集群软件或者ibm powerha for linux版本的都可以

随着企业 IT 的不断发展，那么系统越来越多，数据库也就越来越多。这样就产生了大量的关于资源利用的浪费问题、管理上的纷繁复杂以及人力资源上的冗余投入。于是产生了要对数据库资源进行整合的想法。 那么作为企业的 IT 部门，我们得回过头来考虑考虑数据库资源整合的驱动力...

首先要明确到底要解决什么问题，要搞清楚为了什么整合，整合的维度，个人经验还是从系统的重要程度出发，按照应用是管理类型（olap）还是在线业务（oltp）进行 区分组合。对于分析型的系统通常是体量大重io的库相对oltp 连续性的要求较低，而平时的资源利用率又较低的系统，适合整合到一起...

版本升级和bug的问题无论是否整合都会出现的，版本的升级因该遵循公司的升级测试策略，只是要协调维护的时间。另外bug，如果数据库按照schema 或db 整合，有可能出现全局的问题，影响也会很大。 如果按照实例整合，bug 影响会较小。 对于实时性敏感交易，我的建议是不整合，因为它...

1、两个角度，为了实现要是在系统上区分用户来备份恢复，通常比较复杂，也不利于管理， 整合后由专门的人来负责 备份恢复 相对比较安全 ， 对于有频繁的备份恢复的系统，通常这样的系统都有特殊的要求，比方安全、测试要求都比较高，建议暂时不整合。  2、对于11g的整合，性能问题的规避...

总的来说，如继续使用RAC架构，在控制节点数量的基础上，还是坚持传统“数据分区，应用分区”的原则，合理库表设计，同时考虑合理成本的IO隔离，不同大型应用接入不同实例等；并配合以适当的备份策略，以及容灾方案。可按负荷水平和可管理性，设计多个RAC集群，每一个集群中，可将原不同负荷水平...

分布式数据库到底是提升了成本还是减少了成本，我很迷茫,我的问题是： 1、目前传统数据库整合还能提高多少，到我们公司现在的状况，是不是就已经没有办法整合下去了（目前我公司采用一库多实例），如果能，有什么更好的方案； 解答：（1）集中式数据库整合还能提高多少： 及把数据库端包含的...

oracle数据库在12c多租户之前，都是单实例单数据，11g及以前版本都是通过创建不同的schema进行隔离的；db2和mysql数据库本身都是单实例多数据库的结构，都可以创建不同的数据库进行隔离；