运行在局域网中的一台或多台计算机和数据库管理系统软件共同构成了数据库服务器，数据库服务器为客户应用提供服务，这些服务是查询、更新、事务管理、索引、高速缓存、查询优化、安全及多用户存取控制等。
 

在C/S模型中，数据库服务器软件（后端）主要用于处理数据查询或数据操纵的请求。与用户交互的应用部分（前端）在用户的工作站上运行。它们的连接软件是：

● 数据库服务器应用编程接口API，

● 通信连接软件和网络传输协议。

● 公用的数据存取语言──SQL

相信各位站长在租用服务器的时候，都有出现过服务器数据丢失的情况，数据丢失不可怕，可怕的是丢失后无法恢复，在此教各位几种数据丢失的修复方法：

一、服务器租用的存储非常重要的，这个我想大家都知道，硬盘作为服务器的主要存储设备，硬盘是一种技术含量高、制造精密的设备，服务器硬盘已经达到1万转以上，普通的SATA硬盘也非常接近这个转速，在实际的应用中，一点小问题都可能造成服务器硬盘的故障，所以一般服务器租用都采用 Raid磁盘阵列存储，这样就可以增加服务器硬盘的抗故障能力。

二、除了以上的方法外，对于一些重要的数据还要进行实时的备案，推荐企业用户、商务用户架构的网络服务器，选用磁带机配合专业备份软件(VeritasNetbackup、CAArcserver)，定时进行备份，如果条件允许的话最好能每天备份。

三、因为个人的错误操作原因，导致服务器文件不小心被删除或者丢失的话，可在网上下载一些恢复软件(DataRecove,Easyrecove 等)尝试来进行恢得，当然，做之前可以先用Ghost软件做个磁盘全备份，同时在恢复时最好是接从盘。如果你对自己的恢复结果不满意，还可以到电脑城找专业的数据恢复公司帮你进行硬盘数据恢复。

四、要经常关心服务器的运行状况，对于服务器的指示和警示灯要多留意。一般来讲，服务器租用外观都有每一块硬盘指示灯，正常情况下一般会是绿色，指示灯出现特殊情况时，就需要采用相关措施，仔细检查硬盘设备是否正常。一旦硬盘受损或者出现故障，不要擅自处理，要找有经验的技术人员作出详细检查再作处理方案。

　(1) 减少编程量

数据库服务器提供了用于数据操纵的标准接口API。

(2) 数据库安全保证好

数据库服务器提供监控性能、并发控制等工具。由DBA统一负责授权访问数据库及网络管理。

(3) 数据可靠性管理及恢复好

数据库服务器提供统一的数据库备份和恢复、启动和停止数据库的管理工具。

(4) 充分利用计算机资源

数据库服务器把数据管理及处理工作从客户机上分出来，使网络上各计算机的资源能各尽其用。

(5) 提高了系统性能

● 能大大降低网络开销。

● 协调操作，减少资源竞争，避免死锁。

● 提供联机查询优化机制。

(6) 便于平台扩展

● 多处理器(相同类型)的水平扩展。

● 垂直扩展：服务器可以移植到功能更强的计算机上，不涉及处理数据的重新分布问题。

当一个新的业务系统开发完成后，需要在一个区域乃至全国推广此应用软件，如何根据业务规模来选择服务器配置、内外置磁盘大小、以及网络带宽，是一件复杂的事情。

一个最真实的评估，是建立一个接近真实业务应用的操作环境，进行各种压力测试，测算出不同的用户数量下，系统的响应时间和吞吐量，并得出当时服务器的各种资源的利用率情况，对硬件资源的完整评估，需要考虑下列三个方面:

服务器性能的评估

客户端工作站或前端桌面的评估

通讯网卡和网络带宽的评估

如果不能建立准确的压力测试环境，需要根据工业界的Benchmark对服务器进行评估，推算出符合业务规模的服务器配置,同时要考虑在做系统管理时所消耗的资源，如在做备份、恢复、问题诊断、性能分析时、软件维护时都会对资源带来附加的消耗，对重要资源要考虑为将来留下升级和可扩展的余地，下列是一些通用的原则:

处理器:要考虑高峰时的处理器的能力，并适当保留一些缓冲，确保在业务增长时，系统有扩展的余地。如果要保持快速的响应能力，应当为CPU保留20%至40%的富余量。

内存:要为运行在此服务器的所有应用软件考虑内存，所需要的内存主要依赖于用户数、应用程序类型、进程的方式、和应用程序处理的数据量决定。

磁盘:评估业务的实际用户的数据量，以此推算出磁盘的最小个数，不要忘记选择备份设备(如磁带机)。

IO槽:尽量保留更多的IO槽，防止将来插更多的PCI卡。

网络:选择合适的网卡，保证网络不是系统的瓶颈。

在评估数据库服务器性能时，最困难的事情是如何把握准确度问题，到底考虑哪些因素等。理想情况下，应考虑下列要素:

交易的复杂性

交易率

数据读/写比例

并发连接数目

并发交易数目

数据库最大表的大小

性能度量的目标

根据各种Benchmark测试结果和对各种生产系统的检测，下表概括了CPU、磁盘、内存页面、网络和虚存页交换的利用率，可看出一个服务器如果其利用率保持在Good 所标示的范围内时，是一种理想的模式。

基于rPerf的推算，评估数据库服务器的CPU

rPerf(Relative performance)是从IBM公司解析模型得出的商务处理性能估计值。该模型模拟部分系统的操作，如中央处理器、高速缓存和内存，该模型没有模拟磁盘和网络的输入/输出操作。虽然采用了一般数据库和操作系统的参数，但该模型不能反映出具体的数据库或AIX版本。除非单独说明，否则rPerf均在系统推出时估计。IBM pSeries 640-B80为基准参照系统，其值为本。虽然rPerf可用于比较商业处理性能，但实际的系统性能可能不同，取决于许多因素，包括系统硬件配置和软件设计与配置。

评估数据库服务器的性能，需要理解交易的类型、高峰期的情况、用户数量、在高峰时每个用户的交易数量。假如在高峰时，有三种典型的交易类型:轻的、一般的、重的。需要知道高峰时，每种交易的并发用户数目。假定高峰时间为:10:00-11:00，每个用户的交易数目如下:

轻的交易 =120 交易/用户

一般的交易= 60 交易/用户

重的交易 = 15交易/用户

下面举例说明如何计算所需的rPerf值，假定某公司的情况如下:

业务高峰时间: 10:00-11:00=1Hour=3600秒

交易类型: 无复杂查询的简单应用

相对交易类型，用户数目分布:轻的=2000, 一般=50, 重的=5

在高峰时，每个用户的交易数量:

轻的=120交易/用户

一般=60交易/用户

重的=15交易/用户

对于rPerf=1的服务器，每个交易响应的CPU秒

轻的=1

一般=3

重的=15

最大的CPU利用率:60%

根据上述公式，可推算出不同交易类型所对应的rPerf值。

轻的交易:NU*TX*CS/PP=2000*120*1/3600=66.0

一般交易:NU*TX*CS/PP=50*60*3/3600=2.5

重的交易:NU*TX*CS/PP=5*15*15/3600=0.3

所需的总的rPerf/MC=(66.0+2.5+0.3)/0.7=98.3 rPerf

基于TPC-C的推算，评估数据库服务器的CPU

TPC-C基准是事务处理委员会建立的一个专门演示在线事务处理性能(OLTP)的性能基准，它的测量方法是为了使客户能够评估不同的在线事务处理系统的性能，这些事务进程于一个可控制的状态下在一个标准的数据库中运行。

TPC-C测试包括5个典型的OLTP事务，它们是:

新订单　:一个用户提交一个新的订单

支付　:更新用户的账户余额以反映一个支付

交付　:订单的交付(通过一个批事务处理实现)

订单状态:返回用户最新订单的状态

库存水平:监控当前仓库库存

TPC-C的事务处理是在一个9个表的数据库上实现的事务处理过程包括:更新、插入、删除、终止，以及对主和次级键的访问,每种事务处理90%的响应时间应小于或等于5秒，其中，库存水平的响应时间可以在20秒以内。

TPC-C的吞吐量值是终端活动水平的直接结果，如每一个仓库有10个终端，在每一个终端上上述5个事务都是可用的，一个远程的终端仿真器被用来在性能测试过程中进行必要的事务混合工作。这个混合代表着一个完整的订单商务处理流程:录入、支付、检验、交付。更专业的是，这个必要的混合被定义为产生一个相等数量的新订单和支付事务，以及在每10个新订单事务中产生一个交付事务，一个订单状态检验事务和一个库存水平检验事务

远程终端仿真器也被用来测量每一个事务的响应时间，以及用来模拟键入时间及思考时间，键入时间是指在终端上录入数据所花费的时间，思考时间是指操作人员在终端读取事务的结果，进行下一个事务请求之前所花费的时间。每一个事物都有一个最小键入时间和最小思考时间。另外，这个响应时间必须在一个给定的极限值之下。

TPC-C基准测试的结果--TPC-C的吞吐量(tpmC)，代表的是系统的最大的持续性能，它被定义为系统每分钟可以处理多少个新订单事务，与此同时，系统还在处理其他四种事务类型(支付、订单状态、交付、库存水平)。所有5个TPC-C事务都有某个限定的用户响应时间要求，其中新订单事务的响应时间是5秒以内。因此如果一个系统的TPC-C值是100tpmC/min，说明该系统在每分钟处理其他的混合的TPC-C事务的工作的同时，可以产生100个新订单事务。

如何使用TPC-C进行服务器的评估

由上可知，TPC-C测试基准主要用于测试主机服务器每分钟能够处理的联机交易笔数，测试产生的单位结果是TPM值(Transaction Per Minute，即每分钟处理的交易比数)。

TPC-C虽然客观的反映了各个计算机厂商的系统处理性能，并且测试基准也在不断完善以更加贴近现实应用的交易环境，但是仍然无法与纷繁多样的各类实际应用完全吻合;而且参加TPC测试的主机系统都做了适当程度的系统优化。因此，在实际业务应用系统选择主机服务器乘载体时，必须考虑到多方面的因素，以最大程度的做到适合应用系统的生产需求。

以下计算公式是IBM公司在金融综合业务系统的实际应用中总结的经验方法论，基本反映了金融业务特点对主机处理能力的需求:

TPM=TASK x 80% x S x F / (T x C)

其中:

TASK:为每日业务统计峰值交易量

T:为每日峰值交易时间，假设每日80%交易量集中在每天的4小时，即240分钟内完成:T=240。

S:为实际银行业务交易操作相对于标准TPC-C测试基准环境交易的复杂程度比例。由于实际的金融业务交易的复杂程度与TPC?C标准测试中的交易存在较大的差异，须设定一个合理的对应值。以普通储蓄业务交易为例，一笔交易往往需要同时打开大量数据库表，取出其相关数据进行操作，相对于TPC-C标准交易的复杂度，要复杂很多;根据科学的统计结果，每笔交易操作相比较于TPC标准测试中的每笔交易的复杂度此值可设定为10~20。

C:为主机CPU处理余量。实际应用经验表明，一台主机服务器的CPU利用率高于80%则表明CPU的利用率过高会产生系统瓶颈，而利用率处于75%时，是处于利用率最佳状态。因此，在推算主机性能指标时，必须考虑CPU的冗余，设定C=75%。

F:为系统未来3~5年的业务量发展冗余预留。

综上所述，为保障联机业务处理性能要求，我们可推算得出主机所需的处理能力，据此得出相应的机型和配置。