一般来说,理想的2 4×7数据库系统在体系结构上应该具有以下特点:
* 健壮性 这个数据库系统应该能够自动处理许多系统失败以及数据库失败。并且必须对
每个单一失败点进行标识,同时为每个这种组件提供了相应的冗余组件。
* 透明的失败恢复 系统应该提供最大限度的失败恢复透明性,使得主数据库系统在崩溃
时能够尽量不影响系统的整体可用性。需要说明的是,失败恢复不仅是指数据库系统失
败的检测功能,同时还包括作出相应响应动作的过程。必须提供一种机制,能够周期性
地检测数据库系统的稳定性。如果将这种周期性检查的周期时间设置过短,那么就有可
能会由于经常性的检测动作而导致系统整体性能的下降;而如果将这种周期性检查的周
期时间设置过长,那么就有可能导致数据库系统服务的失败被终端用户所感觉到。此外,
一旦主数据库系统的失败被检测到,所采用的失败恢复策略必须能够重新发现数据库的
新连接路由,以便尽快地与数据库系统建立连接。这时需要注意的是,先前的数据库连
接有可能是活跃的也有可能是非活跃的。其中对于数据库连接的活跃性判断非常关键,
2 4×7方式必须保证数据库连接中的应用程序具有重新启动功能。如果这种功能不能实
现,那么数据库的解决方案中就必须提供一种机制,能够在必要的情况下重新建立应用
程序与数据库系统的连接,从而减少应用程序反复调用数据库的开销。有些时候,数据
库系统服务的中断很容易被数据库访问用户所发现,这是因为用户可以明显地感觉到数
据库系统连接被中断。
* 数据完整性 2 4×7方式下的数据库系统必须保证数据的完整性,不能允许出现数据的
丢失或者数据内部相关性的冲突。例如,在将所有的数据从主数据库系统传送到备份数
据库系统的过程中,不允许出现任何数据丢失的现象。
* 经济承受能力 实现数据库系统的开销以及数据库系统自身的开销,应该低于不采用 2 4
×7方式时的比例。在短时期内,2 4×7方式数据库系统的开销也许会比较高(只要打开
这段时间以来的记帐本就可以发现)。但是,随着时间的推移,这种高开销就会明显地
下降,这是因为2 4×7所带来的效益。关于这一点,只有在将 2 4×7方式下数据库系统的
开销与潜在的系统停工时间所带来的效益损失进行比较才可以发现。在进行损失计算时,
只要考虑在数据库系统访问的高峰期这个特殊情况就可以得到最坏情况下的损失大小。
因为,在其他时间,所造成的损失应该不会大于此时的损失。
* 优化资源使用 2 4×7方式下的数据库系统应该以尽可能优化的方式来使用系统资源,
以便不会到达系统的饱和状态(特别是在数据库系统访问的高峰期)。
* 系统实现的简单性 将公司的数据库系统移植到 2 4×7方式下的工作量不应该过大,并
且系统停工时间以及服务质量的下降(对于用户来说)必须保证在用户可接受的范围之
内(这个范围应该作为考虑系统方式移植的一个因素)。同时,对相关组件(包括应用
程序、安全策略等等)所作的修改必须具有一定的可行性。
* 系统可维护性 必须保证公司内的系统管理人员能够在不求助于不可行方式(例如,频
繁的脱产培训、复杂的维护工具、高级专家顾问的常规性访问)的情况下进行系统维
护。
* 性能 在日常的工作中,新的数据库系统不应该影响系统性能。需要说明的是,某种程
度上的性能影响也许会是不可避免的。例如,如果 2 4×7方式要求所有的应用程序都必
须通过多个数据库(包括位于远程站点的数据库)才能正常工作,那么网络延迟就有可
能会影响应用程序的正常工作。但是,必须保证这种影响在可接受的范围之内。
* 健壮性 这个数据库系统应该能够自动处理许多系统失败以及数据库失败。并且必须对
每个单一失败点进行标识,同时为每个这种组件提供了相应的冗余组件。
* 透明的失败恢复 系统应该提供最大限度的失败恢复透明性,使得主数据库系统在崩溃
时能够尽量不影响系统的整体可用性。需要说明的是,失败恢复不仅是指数据库系统失
败的检测功能,同时还包括作出相应响应动作的过程。必须提供一种机制,能够周期性
地检测数据库系统的稳定性。如果将这种周期性检查的周期时间设置过短,那么就有可
能会由于经常性的检测动作而导致系统整体性能的下降;而如果将这种周期性检查的周
期时间设置过长,那么就有可能导致数据库系统服务的失败被终端用户所感觉到。此外,
一旦主数据库系统的失败被检测到,所采用的失败恢复策略必须能够重新发现数据库的
新连接路由,以便尽快地与数据库系统建立连接。这时需要注意的是,先前的数据库连
接有可能是活跃的也有可能是非活跃的。其中对于数据库连接的活跃性判断非常关键,
2 4×7方式必须保证数据库连接中的应用程序具有重新启动功能。如果这种功能不能实
现,那么数据库的解决方案中就必须提供一种机制,能够在必要的情况下重新建立应用
程序与数据库系统的连接,从而减少应用程序反复调用数据库的开销。有些时候,数据
库系统服务的中断很容易被数据库访问用户所发现,这是因为用户可以明显地感觉到数
据库系统连接被中断。
* 数据完整性 2 4×7方式下的数据库系统必须保证数据的完整性,不能允许出现数据的
丢失或者数据内部相关性的冲突。例如,在将所有的数据从主数据库系统传送到备份数
据库系统的过程中,不允许出现任何数据丢失的现象。
* 经济承受能力 实现数据库系统的开销以及数据库系统自身的开销,应该低于不采用 2 4
×7方式时的比例。在短时期内,2 4×7方式数据库系统的开销也许会比较高(只要打开
这段时间以来的记帐本就可以发现)。但是,随着时间的推移,这种高开销就会明显地
下降,这是因为2 4×7所带来的效益。关于这一点,只有在将 2 4×7方式下数据库系统的
开销与潜在的系统停工时间所带来的效益损失进行比较才可以发现。在进行损失计算时,
只要考虑在数据库系统访问的高峰期这个特殊情况就可以得到最坏情况下的损失大小。
因为,在其他时间,所造成的损失应该不会大于此时的损失。
* 优化资源使用 2 4×7方式下的数据库系统应该以尽可能优化的方式来使用系统资源,
以便不会到达系统的饱和状态(特别是在数据库系统访问的高峰期)。
* 系统实现的简单性 将公司的数据库系统移植到 2 4×7方式下的工作量不应该过大,并
且系统停工时间以及服务质量的下降(对于用户来说)必须保证在用户可接受的范围之
内(这个范围应该作为考虑系统方式移植的一个因素)。同时,对相关组件(包括应用
程序、安全策略等等)所作的修改必须具有一定的可行性。
* 系统可维护性 必须保证公司内的系统管理人员能够在不求助于不可行方式(例如,频
繁的脱产培训、复杂的维护工具、高级专家顾问的常规性访问)的情况下进行系统维
护。
* 性能 在日常的工作中,新的数据库系统不应该影响系统性能。需要说明的是,某种程
度上的性能影响也许会是不可避免的。例如,如果 2 4×7方式要求所有的应用程序都必
须通过多个数据库(包括位于远程站点的数据库)才能正常工作,那么网络延迟就有可
能会影响应用程序的正常工作。但是,必须保证这种影响在可接受的范围之内。