数据库系统管理与优化论文

数据库系统管理与优化论文（精选12篇）

数据库系统管理与优化论文 篇1

《办公设备报修管理系统》是专为我局及各台站设计开发的日常办公设备报修、维护管理系统, 系统集成了报修、维修、请料、人员管理等多项管理功能, 能有效解决各台站的设备维护报修环节中因步骤较为繁琐、信息传达不到位导致设备维护效率低的问题。

1 数据库表设计

本系统设计了login登录信息表、repair Information维修信息表、resource资源使用表、media多媒体信息表。

1.1 登录信息表

登录信息表 (login) 用于存储管理人员、职工、维修人员的基本信息, 登录信息表需要满足系统对人员的基础信息记录要求, 其中设计字段包括人员姓名 (登录名) 、登录密码、用户权限、用户性别、用户年龄、用户部门、

用户电话、申请注册时间和用户状态等。由于系统设计预留与人事部门的接口, 所以在用户注册过程中, 需要根据用户部门、性别、年龄、电话等信息与人事数据库进行比对, 所以在数据库中设计上述字段, 同时工作部门和联系电话可以方便维修过程中的必要联络。为了满足不同用户有权限执行系统的不同功能的需求, 设计用户权限字段, 通过用户权限保证用户对应的操作级别。

具体表结构与设计详见表1。

1.2 维修信息表

维修信息表 (repair Information) 用于存储维修过程中产生的信息, 为保证数据简洁有效, 减少数据冗余, 所有维修中产生的信息均记录于本表中。表中设计维修单号、申请人员、申请时间、故障类型、紧急程度、故障地点、其他信息、审批人员、审批时间、维修人员、维修时间、维修信息、满意程度、维修单状态共14个字段, 其中维修单号为主键, 采用表自动编号方式记录。

表中申请人员、审批人员和维修工人字段均为外键, 其主表为登录信息表。表中故障类型字段分为三个等级:一般、紧急和特急。一般和紧急状态的维修单需要经过管理人员审批后才能派单至维修人员, 特急状态的维修单直接下派至维修人员。维修信息字段是为了记录维修过程, 将维修人员与申请人员的交互信息做详细记录, 可以为后期的纠纷解决提供一定的帮助。满意度字段分为非常满意、满意、一般和不满意四个状态, 用于记录申请人员对维修人员维修情况和服务情况的主观评价。维修单状态字段用于标记维修单的状态, 维修单的状态由操作用户根据一定的规则写入, 用来标记维修单的当前信息。一旦维修单状态标记为完成状态, 则维修单不允许任何人进行修改, 仅能做查询和统计分析。

具体表结构与设计详见表2。

1.3 资源使用表

资源使用表 (resource) 用于记录在维修过程中使用的材料情况。资源使用表设计使用标识、资源名称、资源数量、资源使用、资源使用时间和资源花销共6个字段, 其中使用标识为主键, 采用表自动编号方式记录。

表中资源使用为外键, 用于记录使用资源的维修单号, 其主表为维修信息表。表中资源花销字段是指本次资源使用的总费用, 费用记录是由系统调用财务器材科接口, 通过使用的资源价格乘以资源数量计算得出。

具体表结构与设计详见表3。

1.4 多媒体信息表

多媒体信息表 (media) 用于记录图片视音频信息。多媒体信息表设计文件名、维修单、文件路径、媒体类型、上传者和上传时间6个字段。由于报修系统要求在报修过程中可以使用图片、声音和视频等方式上传故障信息, 所以本表的作用是将上传的文件信息和保存路径做详细记录, 以供调用。其中文件名为主键。文件名的命名使用时间为名称, 在上传至系统过程中, 由系统直接更名。

其中维修单字段和上传者字段为外键, 分别记录多媒体信息归属的维修单和上传用户登录名, 主表为维修信息表和登录信息表。媒体类型字段是为了方便系统后期调用显示多媒体信息。

具体表结构与设计详见表4。

2 遇到的问题和解决办法

在系统软件压力测试过程中发现, 当数据库中的维修数据量较小时, 系统读取数据反应速度较快;当数据库中数据量较大时, 软件系统反应速度慢, 同时数据库服务器负荷较大。

经测试发现, 由于系统软件设计需要推送信息至用户, 即用户端定期读取数据库中的维修信息, 查找符合一定条件的数据进行推送显示, 这致使数据库的读取压力倍增。

针对这一问题, 在尽可能少更改系统软件的前提下, 对数据库进行优化, 以达到系统使用要求, 经过分析总结, 有两种方案针对数据库的优化设计。

(1) 精简数据库中维修信息表的数据量

这种方案需要针对已经完成的维修数据信息做删除处理, 或者将维修数据转移至其他存储表中。这样就会使软件系统获取的推送数据仅维持在未完成的维修单信息之中, 减少数据的吞吐量, 达到系统性能。

(2) 在数据库中设计“快表”

快表 (Cache) 用来存储未完成的维修信息单状态, 以便系统推送使用。快表设计快表标识、权限、登录名、快表状态、标识信息、标识时间、占有标识和阅读状态共8个字段。

综合考虑, 我们采用第二种方案, 在数据库中建立快表来满足系统要求。经过测试, 数据库中维修信息表的数据量在到达5万条时, 15人在线使用此系统运行正常, 数据库服务器运行正常。

3 总结

本数据库的设计在满足软件系统设计的同时, 针对数据库凸显的问题做出了优化设计, 在保证数据安全和有效的前提下, 提高了数据库和系统软件的运行速度, 成为了系统的有力支撑, 促使办公报修管理系统顺利投入试运行, 也为台站自动化建设提供了有力的支持。

数据库系统管理与优化论文 篇2

一、总体要求

本科目考试为情报学初试科目，涉及二门必修课程，管理信息系统、数据库原理与应用。考试的目的在于考查考生对基本概念、基本理论的掌握，运用基本理论与基本方法分析和解决实际问题的能力。

二、考试范围与要点

（一）数据库部分数据库系统概述

数据库系统概述、数据模型、数据库系统结构、数据库系统的组成等；关系数据库基本理论

包括关系数据库定义、关系操作、关系规范化、关系处理与查询优化等；关系数据库标准语言SQL

SQL语言概述、SQL语句的表达等；数据库控制

包括数据库安全性、数据库完整性、数据库并发控制、数据库备份与恢复等；数据库设计

数据库设计概述、需求分析、概念结构设计、逻辑结构设计、数据库的实施和维护等。

（二）管理信息系统部分管理信息系统概述

信息技术与企业管理、信息系统在组织中的作用、信息系统、信息系统的类型、数据与信息、管理系统与管理决策、管理信息系统及其结构、信息系统的技术基础、Web开发的基本技术 2 管理信息系统的规划与开发

系统规划、系统规划常用的方法、企业流程重组、系统开发的思想和方法、管理信息系统的开发过程与方法、系统开发方式管理信息系统的系统分析

系统分析、现行系统的详细调查、组织结构与业务流程分析、用户需求分析、数据流程分析、数据流程图、数据字典、描述处理逻辑的工具、新系统逻辑模型的建立、系统分析报告 4 管理信息系统的系统设计

系统设计的目标和原则、功能结构图设计、代码设计、输入设计、输出设计、数据存储设计、处理流程图设计、用户界面设计、系统物理配置方案设计、系统设计文档

5管理信息系统的系统实施与维护

系统实施步骤、软硬件购置、程序设计、数据库实施、系统测试、系统切换、人员培训、系统实施文档、系统维护、系统评价信息系统管理

信息系统开发的项目管理、信息系统的运行管理与维护、信息系统管理模式与伦理企业资源计划

信息集成、制造资源计划（MRP）、MRP II、供应链管理、企业资源计划（ERP）

三、试卷分值与各部分所占比例

试卷满分150分，其中数据库部分占50%，管理信息系统部分50%。

四、考试形式与考试时间

考试采用闭卷笔试的形式，答题时间为180分钟。

五、试卷结构、题型与答题方式

试卷分为数据库和管理信息系统两个部分。题型包括：基本概念考核（填空题、选择题、名词解释等），计算与设计题（考察基本技能掌握与应用），综合分析题（问答题、分析应用题、论述题等）。

答题过程不需要使用计算器，所有解答均写在答题纸上。

六、参考书：

1．王珊，萨师煊著，数据库系统概论（第4版)，高等教育出版社，2006.5

2．黄梯云等，管理信息系统（第四版），高等教育出版社2009

数据库系统管理与优化论文 篇3

【关键词】E R P系统；优化；操作；规范

【中图分类号】X937【文献标识码】A【文章编号】1672-5158（2013）02-0092-02

一.ERP系统简介

ERP，即企业资源计划，是指建立在信息技术基础上，以系统化的管理思想，为企业决策层及员工提供决策运行手段的管理平台。ERP系统集中信息技术与先进的管理思想于一身，成为现代企业的运行模式，反应时代对企业合理调配资源，最大化地创造社会财富的要求，成为企业在信息时代生存、发展的基石。

企业资源计划ERP（ Enterprise Resource Planning）是从物料需求计划MRP（Material Requirement Planning）发展到制造资源计划MRPII（Manufacturing Resource Planning），再进一步发展到企业资源计划大致经历了以下几个发展阶段：

1、 20世纪60年代，美国IBM公司的约瑟夫.奥列基博士运用计算机技术提出来把企业产品中的各种所需物料分为独立需求和相关需求两种类型的概念，并按时间确定不同时期的物料需求，产生了解决库存物料订货的新方法，即物料需求计划（MRP）法。

2、 20世纪70年代，物料需求计划MRP经过发展和扩充逐步形成了制造资源计划MRPⅡ（Manufacturing Resource Planning）的生产管理方式。MRPⅡ主要涉及：企业经营计划、物料需求计划、生产计划、销售计划、物料管理（库存管理与采购管理）、财务管理、成本管理等。MRP Ⅱ系统实现了物流、信息流与资金流在企业管理方面的集成，它是一个完整的闭环企业计划和控制系统。

3、 20世纪90年代以来，制造资源计划MRPⅡ经过进一步发展完善，形成了企业资源计划ERP（Enterprise Resource Planning）系统，它管理的企业资源更多，管理覆盖面更宽。 MRP是ERP的核心，而MRPⅡ是ERP的重要组成部分。

企业资源计划ERP（ Enterprise Resource Planning）是目前最先进的管理模式之一，它是建立在信息技术基础上，以系统化的管理思想，实现最合理的配置资源、来满足市场的需求，它是企业规模化、市场化、竞争化、网络化的必然产物。

ERP系统在企业的应用，实现了信息的“一次采集，高度共享，多层应用”，大大提高了数据采集速度，为经营决策赢得了时间。

二.系统性能及数据质量下降原因分析

但随着系统长期运行， ERP系统性能及系统数据质量往往会呈下降态势。系统反应慢或者存在无用数据将导致停机和挫折感，如果情况更进一步恶化，在最糟糕的情况下，将不再拥有运行业务流程所必须的吞吐量。结果是业务运行超时、延时、错误判断以及经济损失。

产生这一问题原因是多方面的，但究其根本重点在于以下两点：

1.系统原因，其中包括硬件瓶颈、数据库调优、系统调整、客户端配置以及网络状况等，如果这些问题不能及时发现及时解决，将对系统性能造成影响。

2.人为操作不规范，没有形成一个良好的使用习惯。例如操作失误产生大量的无用信息、流水式作业同时产生多条订单和执行收货事务后不关闭界面造成对物料主数据的锁定等，这样不但给系统效率带来影响，同时一个人的操作还可能影响到其他人的正常操作。

三.解决方案

就以上两点主要原因，应该采取以下措施：

1 消除硬件瓶颈，优化系统参数配置，提高系统性能

1.1 消除硬件瓶颈，规避运行风险

ERP系统长时间地运行，设备的CPU、内存、硬盘等硬件设备不间断地工作，硬件老化情况将不可避免地发生。同时随着数据量的增加以及业务种类的不断增加，硬件资源不足导致瓶颈出现，造成系统性能降低。这就要求我们必须时刻关注硬件设备运行状况，了解系统负载的极限值，并针对需求添加硬件配件，例如增加硬盘、内存等，并及时对超期服役的设备进行更换，这样不但可以有效降低硬件瓶颈，同时还可以规避设备老化带来的故障隐患。

1.2 加强数据库监控，定期进行优化

随着系统的运行，数据库的规模也在不断扩大，往往常用表里的数据量都已经突破了百万条，如果不能有效地对数据库进行优化，严重的将导致业务运行超时从而给公司的正常经营带来影响。针对这一问题，我们可以对数据库进行如下调整：首先是对数据库缓存区和其他数据库参数进行优化设置；其次是对数据库硬盘的规划设计进行优化，使得在硬盘上尽可能的平均分配工作负载，以避免当从硬盘中写入和读取的时候产生等待的情况；最后是对耗时的SQL语句，也就是长时间运行的SQL语句的优化，并创建有效率的索引。另外还应该加强对数据库的监控，特别是锁和队列的情况，及时扩充表空间大小，并在月结前调整好数据库，例如参数优化、重建低质量索引等。

1.3 根据需求调整系统配置，优化ABAP程序

系统调整即ERP系统本身BASIS部分及程序部分的调整。首先，根据业务运行要求分配进程数量。例如在白天由于线上操作较多，可将对话进程数量加大；而在晚间后台作业增多，可以减少对话进程数量增加后台作业数量。此举可以满足不同时间段系统的要求。其次，实例参数的调整。例如，系统缓存区（buffer）。对于应用服务器，程序、表和字段定义以及关于客户化表的数据在缓存区中被保持。如果进行优化配置，这些缓存区将确保从数据库服务器中只需直接读取最少量的数据，从SAP缓存区读取数据的速度大约比从数据库服务器中读取数据速度快10-100倍。第三，通过系统工具分析ABAP程序，对消耗资源庞大的程序进行优化，同时优化接口程序，减少不必要的系统开支。

1.4 关注网络运行状况，减少数据传输量

客户端/服务器架构中不同层之间的网络传输速度和数据吞吐量非常重要，他们会影响整个系统的性能表现。如果网络存在瓶颈，将导致客户操作缓慢。另外由于SAP架构要求绝大多数的数据交换都在应用层和数据库层进行。通过优化明显耗时占资源的SQL语句可以减少这种交换；但是在实际中，应用层和数据库层将通过局域网连接。另一方面，由于网络连接可以通过局域网或者广域网实现，这就要求在表示层和应用层之前的数据传输要尽可能的少。

2 完善制度，加强培训、采取有效措施规范操作习惯并加大监控力度降低错误发生概率

2.1 制定全面的管理制度，有效防范系统风险

众所周知，无论一套系统功能如何强大，设置如何完善，但是总会存在人为操作带来的风险。这就给企业的正常业务开展带来了极大地隐患 。所以，一方面，我们要继续完善系统，把风险降低到最小程度，另一方面 ，为规范公司ERP上线后的应用与运行管理，加强对ERP运行的组织和领导，健全ERP运行管理和支持体系，加强对ERP运行绩效的检查和考核，确保系统长期安全、稳定、优质、高效运行，全面支撑企业日常生产、经营和管理，持续提升企业整体管理水平，提高经济效益，就是要制定一套完善的系统管理规范制度。

企业在准备应用ERP系统之前，需要理智地进行立项分析：企业是不是要投资ERP系统？为什么投？何时投？ERP系统是否能够解决目前企业存在的问题？在财力上企业能不能支持ERP的实施？基础管理工作有没有理顺或准备在上ERP之前让咨询公司帮助理顺？必须将分析的结果写成需求分析和投资效益分析正式书面报告，从而做出是否上ERP项目的正确决策。避免盲目性投资。

企业必须大胆改革原有的管理体制，“一把手”要具有企业家精神。企业“一把手”的大胆改革和创新、实施的决心与积极参与度是项目成功实施的根本保证。而大胆改革和创新就要转变观念，真正意义上解放思想，树立正确的人生观、价值观、权力观，以大局为重，以企业的发展为目标，少些私心杂念，只有把企业当作自己家的企业，企业发展才是根本。

企业一旦决定上ERP项目，领导首先要高度给予重视，落实资金是首要任务；其次，企业实施ERP项目要根据企业所在行业的特征以及目前的状况，制定一个完整详细的实施计划和实施范围；第三、培训是成功实施ERP系统的重要因素，包括思想上的培训和知识技能上的培训。另外，加强沟通与合作，出现问题要及时沟通。

在实施的过程中，首先构建与ERP相适应的企业文化，“取其精华，剔其糟泊”，弘扬和培育与之相适应的先进的文化，并将国内外优秀的文化有机地融合。我们在引入ERP美国式的企业文化时还要注意吸取中华民族自身的优秀文化，把ERP的管理思想与中国的实际相结合，在兼收并蓄的基础上进行融合，最终形成自己特色的企业文化。

2.2 加强对系统最终用户培训，同时深化ERP思想

ERP系统管理精细，面面涉及，但往往给人操作繁琐的感觉。对于常用事务或许操作得心应手，但部分不常用事务可能会出现操作失误的情况。同时每年新入职的新员工因为从未接触过ERP系统，对操作更是一窍不通，如果盲目上手，带来的后果也是不堪设想。另外，ERP作为一种管理思想，作为最终用户也应该去深入理解，如果只把它看成是一个操作软件或者一个累赘，那就失去了使用它的意义。这就要求各相关部门定期对最终用户操作合格性进行检查，并制定奖惩制度，同时不定期的及时向ERP支持中心提交培训需求和培训人员名单，加强对最终用户的培训力度。通过培训要使每个最终用户在系统中的操作规范，同时还要让他们明晰业务流程，了解ERP的内涵，提高最终用户的内功，为系统的数据质量和安全提供的有力保障。

2.3 加强对最终用户操作的监控力度，最大限度降低误操作带来的影响

加强对最终用户的培训可以规范其操作，但误操作的情况还是可能会出现。这些误操作造成的垃圾数据往往只有在对账的时候，由于已经过去一段时间，误操作的原因和人员已经无法追查。但在企业SAP运作中，SAP生产系统是整个企业的根本，任何数据的更改、后台设置的更改、系统参数的更改，都会对整个企业的数据流、业务流产生很大的影响，因此对于生产系统在上线以后数据出口一定要有严格的策略进行管控。

在现有系统情况下启用审计功能就显得很必要了。SAP审计功能主要包括：

1）用户登陆及进程监控

2）文件类型已经文件变更纪录

3）开发纪录

4）系统日志文件审计

这样以来，在每日进行数据检查的同时检查近三天人员操作情况，可以有效的锁定误操作的人员，这样对查明原因、纠正其错误都有着积极的作用。

同时还要强化管理，分工协作，建立了完善的运行维护管理体系。笔者经过对信息应用系统进行分析，按信息人员的业务侧重点进行分工，对SAP系统要至少确定1 名信息人员进行维护，确定了第一责任人，加大对系统的监控力度。同时制定了严格的考核制度，将日常运行维护工作进行量化考核，并作为对信息人员绩效考核的主要内容。针对信息人员少，工作量大的特点，制定了首问负责制度，杜绝了在排除系统、设备故障时的推诿扯皮现象。

2.4 采取有效措施规范操作，建立良好的操作习惯

在每日的系统检查过程中，发现很多最终用户往往会打开多个界面操作执行同一个程序，例如一个用户同时打开5个界面并一起执行。也许一两个人操作对系统效率影响不大，但在月结时对系统的压力就显现出来了，服务器整体效率下降明显。针对这种情况，可以采取更改系统参数，限制账户登录窗口打开个数为2个：一个执行业务操作，另外用于查询数据使用；同时限制一个账户只可以同时一人进行登录，另外配合审计日志也可以查到账户登录终端名，最大限度杜绝多人使用同一账户情况出现。这样可以给最终用户建立一种良好的操作规范和操作习惯，有利于系统的正常运行和风险规避。另外，针对在业务繁忙时做大量查询的情况，可以在月结前后摘除部分人员的部分报表查询权限，从而降低服务器的负荷量。同时有效运用系统组登录功能，均衡系统负载，使系统得到最大化的利用。

3.结束语：

ERP项目成功的关键在于企业要创建崭新的、比较适应的、中西方相结合的企业文化。企业文化较为完善并与之相适应是关键，要把中西方文化与自己企业特有的文化有机地结合在一起。企业还必须制定较为明确的实施目标以及远景规划，从管理的角度来组织，而不是简单的软件采购行为。企业领导要具备企业家精神，要有现代管理理念，管理制度和企业运行的管理机制要健全，项目实施需要的资金要有保证，基础设施完备，人员培训较为充分，人员的素质要适合实施的需要，企业在实施ERP项目时困难要相对小一些，时间会短一些，成功的把握也会更大些。

参考文献

[1] 希格里德·哈格曼，蓝·威尔 著，黄兆森 译 《SAP R/3系统管理》

[2] 黄佳编 著 《SAP业务数据传输指南——图灵SAP技术丛书》

[3] 黄骁俭等 著 《中小企业信息化与SAP系统实现/SAP管理实践丛书》

数据库系统管理与优化论文 篇4

随着计算机程序开发技术的快速改进和提升,分布式管理系统功能越来越多,系统集成也变得更加复杂。云计算、B/S体系架构等技术的诞生,将分布式管理系统划分为多层次架构,这样就可以把数据存储、访问和操作独立出来,形成一个逻辑独立的体系架构。因此,数据库作为分布式管理系统的一个重要组成部分,数据的访问、操作速度直接影响系统响应能力。数据库操作优化可以尽可能地缩小数据库连接、插入、删除、修改和查询时间,提高数据库执行速度,从而改进系统响应能力。

2 数据库在分布式管理系统中的应用

数据库在分布式管理系统的应用主要包括以下几个方面:

(1)数据库连接。分布式管理系统前台页面输入请求信息之后,Web服务器接收该信息,并且按照Web服务规则对逻辑业务请求进行解析,将数据库处理信息分离出来,并且请求数据连接,以便建立一个访问数据库的桥梁。

(2)数据库插入。数据插入是分布式管理系统更新操作之一,其可以利用SQL程序设计的INSERT语句将数据插入到数据库中,实现分布式管理信息添加功能。

(3)数据库删除。数据库删除操作可以根据用户请求,利用DELETE语句将数据信息删除。数据库删除操作可能涉及多个数据表,因此操作时间非常长,容易造成系统处理瓶颈,大大地降低响应速度。

(4)数据库修改。数据库修改操作可以利用UPDATE语句修改相关的数据信息,以便能够更新数据库的相关内容。

(5)数据库查询。数据库查询操作可以利用SELECT语句查询数据信息,并且将结果封装到一起反馈给用户,供用户查看数据库查询信息。

数据库操作作为分布式事务处理过程,一个分布式事务可以划分为多个子事务,这样每一个事务都包含了多个操作命令,为了能够将分布于不同位置的数据库集成到一起,每个子事务就必须加载到相关的关联场地,并且在场地中激活每一个子事务。分布式数据库事务处理过程中,需要尽可能地保证分布式事务的原子性、一致性、独立性和持久性。因此,分布式管理系统数据库事务处理存在两个关键问题,分别是分布式事务的管理、网络中各个场地的局部数据的集成。分布式管理系统引入移动Agent技术之后,可以把每一个子事务都封装到一个移动的Agent中,移动Agent能够在分布式网络中进行自由的移动,将移动Agent分发至数据库事务处理的场地,子事务将会在产地上得到有效的处理并且将处理结果反馈给移动的Agent,如果任意一个子事务需要与其他子事务进行分布式计算,则可以移动Agent到新的场地,执行相关的运算,然后携带计算结果返回到原场地。

3 数据库操作组件优化

为了提高数据库操作速度,提出采用移动Agent方法改进数据查询、插入、修改、删除和连接操作。移动Agent分布式数据库事务处理模型包括3个方面,分别是方案Agent、协调Agent和全局数据管理Agent,这3个构件可以形成一个群体,负责全部或局部更新、查询操作,实现对数据库的集中管理、分布式映射和数据控制等功能。另外,通信管理Agent、监控Agent、局部数据管理Agent和局部方案Agent也构成了一个局部群体,可以负责数据库场地自治、转换和交互。分布式数据库引入移动Agent后操作处理流程如图1所示。

具体的数据库执行过程中各个Agent功能描述如下:

(1)方案Agent。方案Agent的功能是维护全局和局部数据目录,比如能够管理数据库全局模式、局部名映射、描述分配、数据库存取方法、完整性约束信息、数据表达格式等信息。从全局方面管理数据库操作信息,便于用户处理。

(2)协调Agent。协调Agent的功能是控制和协调分布式数据库事务处理流程、规则,以便按照正确的顺序提交、处理和终止数据处理过程,进一步改进数据库的操作有序化、规范化。

(3)全局数据处理Agent。该Agent的相关功能是完成数据库数据信息的查找、定位操作,以便协调各个Agent之间的信息交互管理功能,通过方案Agent查询全局或局部数据库目录,进一步实现数据转换功能。

(4)调度Agent。调度Agent可以负责局部数据库的操作链接功能,并且能够将逻辑业务请求发送给相关的局部数据处理Agent,这样就可以实现程序调度和管理。

(5)监控Agent的功能是负责实时监控局部数据库的变化,并且将相关的状态信息通知给方案Agent,促使其改变全局或局部数据库目录。

(6)通信管理Agent的功能是负责各个场地之间的数据传输等功能,当监控Agent监控到局部数据发生变化时,通信管理Agent可以将变化传递给其他关联场地副本,如果需要对其他的局部数据库实施操作,还可以移动到其他的场地。

(7)局部数据处理Agent的功能是更新、查询局部数据库,并且能够实现数据转换等功能。

数据库任务查询设计的物理表很多,因此查询过程中需要进行严格优化操作,数据库事务查询引入移动Agent之后,可以采用的查询方式包括普通查询模式和增强型查询模式。普通查询模式可以将查询任务划分为多个逻辑独立的子查询任务,因此一个主Agent可以创建多个逻辑独立的子Agent,每一个Agent能够完成一个子查询任务,并且通过分布式网络可以将查询任务分发到多个目标场地进行执行,然后主Agent可以集成和封装子Agent的查询结果,并且按照组装规则生成一个完整的查询结果,如图2所示。

数据库任务查询的另一种模式是增强查询模式,主Agent创建一个增强型的主Agent,增强型主Agent创建多个子增强Agent,并且将逻辑独立的子查询任务加载到子增强Agent上,将其分发至每一个目标场地。查询事务完成之后,由增强型的主Agent负责操作、组合查询结果,并且将最终的结果反馈给主Agent。由于增强型的主Agent无需在客户端上组装,因此可以保证客户端操作的完全透明性。如图3所示。

为了显示算法的优越性,论文设置了一个100次的数据库删除操作,传统的数据库处理时间为26.7s,引入移动Agent模型之后执行时间为14.2s,大大地降低了执行时长,提高分布式事务处理速度。

4 结语

数据是分布式管理系统加工、处理的对象,因此数据库的处理速度直接影响分布式管理系统的响应时间。为了提高系统处理效率,引入了移动Agent优化数据库操作过程,实现数据分布式、透明化处理,实验结果显示算法可以改进系统处理时间,进一步改进算法优化效率。

摘要：互联网、大数据、云计算等技术的快速发展,促进了分布式管理系统在电子商务、电子政务、金融证券、电力通信等领域得到广泛普及和使用,取得了显著的应用成效。分布式管理系统在数据处理过程中,数据库是最为关键的一个重要组成部分,其承载着系统数据的连接、查询、删除、修改、插入等操作功能,直接影响分布式管理系统的操作性能。分析了数据库在分布式管理系统中的应用,提出了利用Agent技术优化数据库操作组件,提高系统数据加工的速度,进一步提升系统性能。

关键词：数据库,分布式管理系统,Agent技术,操作组件

参考文献

[1]孔令媛.远程分布式数据库查询系统的设计研究[J].信息通信,2015,(12):133-134.

[2]申毅,武小年.分布式异构数据库数据同步系统的实现与优化[J].桂林电子科技大学学报,2014,(4):285-289.

[3]李春晓.基于Hive的分布式空间数据库的研究与优化[D].河南大学,2015:1-7.

[4]周跃,臧斌宇.分布式No SQL系统写操作性能优化设计与实现[J].计算机应用与软件,2014,(11):25-28.

数据库系统管理与优化论文 篇5

航天试验测发网络计划动态优化管理与决策支持系统

对建立航天试验测试发射组织指挥网络计划实时动态优化管理与决策支持系统的设计思想、设计方案及相关部件的基本功能做一简要的`介绍.指出在复杂大系统工程项目计划中,利用网络计划技术进行动态优化管理与决策是工程项目计划管理与决策的一种有效途径.

作 者：陈浩光 陈庆华 杨惠鹄 佟连捷 Chen Haoguang Chen Qinghua Yang Huigu Tong Lianjie 作者单位：国防科工委指挥技术学院,北京,101416刊 名：系统工程与电子技术 ISTIC EI PKU英文刊名：SYSTEMS ENGINEERING AND ELECTRONICS年，卷(期)：199921(9)分类号：V2关键词：航天技术 网络分析 决策支持系统 系统工程

数据库系统管理与优化论文 篇6

关键词：人员定位；数据库；优化

中图分类号：TP311 文献标识码：A 文章编号：1009-3044（2016）18-0013-02

井下人员定位系统是利用无线射频技术RFID、数据库、通信和计算机技术来实现对井下人员的跟踪定位信息的采集、分析处理、实时显示、数据库存储、考勤管理及报表打印等功能。实现地面管理人员对井下人员实时分布、轨迹等进行实时管理，从而达到在灾变发生时为抢险救灾提供科学可靠的依据。

煤矿采用三八制或四六制工作方式，每天24小时不间断的生产，所以下井人员众多，若要实现井下有效定位，满足国家规定，井下基站也需要很多。所以系统每天都要产生大量的数据记录，以一个年产300万吨的煤矿为例，按三八制计算，每班大概需要500人下井，每人来回大概要经过30个基站，假设每经过一个基站产生一条记录，每天产生3×500×30=45000，每月产生45000×30=1350000条记录，按国家要求井下信息至少要保留6个月，1350000×6=8100000条记录。所以，要对这些原始数据进行有效的管理利用，对数据库的设计与优化就显得非常必要。

1数据库设计

数据库在一个信息管理应用软件系统中占有非常重要的地位，数据库结构设计的好坏将直接影响系统的效率以及实现的效果。合理的数据库结构设计可以提高数据存储的效率，减少数据的冗余，保证数据的完整性和一致性。

1.1 数据库概要设计

下井人员携带标识卡（tag标签），经过安装有基站（读卡器）的位置时，基站读取人员所携带的标识卡，把标识卡的ID号和读取时间上传到监控中心的数据采集主机上并保存到实时数据表中，系统依据系统所采集的原始数据再与其他相关的关进行关联处理，生成一些其他相关信息表，并保存在相应的数据库中，供管理员用户查询利用。根据系统所涉及的实体以及它们之间的关系可以画出系统实体关系（E—R）图。系统的E—R图如图1所示。

1.2 数据库逻辑设计

根据人员定位管理系统的功能及系统所涉及的实体以及它们之间的关系，建立以下主要表：管理员信息表、用户信息表、部门信息表、基站信息表、识别卡信息表，以上这些表相对修改的机会较小，一般建立完成后变动很少，所以把这些表称为静态表；在系统中由于井下人员移动所产生的轨迹通过基站传到监控中心，监控中心的数据采集主机就把这些信息保存在一个表中，这个表称为轨迹表，这个表存储员工在井下的行走轨迹，所以随着时间的推移，这个表的数据量会急剧增加，而系统所查询信息的生成都要依靠这个表而产生，所以这个表的大小直接影响系统的效率，这个表称为动态表。以下列出系统部分表的结构。

（1）基站信息表

基站信息表用来存储基站的相关信息，其详细表结构如表1所示。

（2）识别卡信息表

识别卡信息表用来存储识别卡的ID、编码、电压、当前状态、删除标记以及所属人的ID号信息，其具体表结构如表2所示。

（3）井下人员轨迹信息表

井下人员的信息是系统的基站采集的，为了减少传输的信息量，系统只采集了基站ID、识别卡ID和读识别卡的时间，所以这个表的只有四个字段，其具体表结构如表3所示。

2 数据库优化

数据库设计应满足完整性、一致性、最小冗余等要求，但是在进行实际数据库设计时并不一定要完全遵守数据库设计规则，要根据系统实际需求进行设计。

2.1 表结构的优化

1）由于人员定位系统的特殊性，数据要求至少保存半年以上，特殊数据要保存至少一年以上，而且井下轨迹记录不允许用户进行修改，为了防止用户对员工下井信息进行篡改，所以井下人员信息表增加eventID字段，用来记录井下记录的自增ID号，若用户进行删除或添加信息就会从ID号上反映出来。

2）人员定位的数据要保存一定的时间，而井下人员的轨迹及相关的统计考勤等信息都依赖于井下人员轨迹表。如一个人的下井轨迹是要通过井下人员轨迹表中的tagid与员工信息表中的cardid进行关联才找到这个人的信息，再通过员工信息表中的departid找到这个人的部门的相关信息，通过tagid可以找到卡的编码的相关信息，所以各个表之间都是通过相应的id号进行关联的，所以当一个人离岗时，他的信息不可真的删除，只能加一个删除标记，以便系统能找到相关人员的历史信息，同理他原来的卡的信息也不可直接删除，只能加一个删除标记，防止其他人的轨迹信息与现在卡号所对应人的信息关联在一起，导致数据前后的不一致。所以对数据库中易导致数据前后不一致的表都增加了一个is_deleted字段，用来标记此记录被删除。

2.2 查询的优化

为了提高系统查询的效率要对表中的关键字要建立索引，同时要尽量减少表之间的关联，表之间关联条件的选择也非常重要。

2.3 表的优化

由于井下人员轨迹表随着时间的增加数据会急骤增加，如果不对此表进行有效的分流，会严重影响系统的效率，甚至会导致系统的崩溃。监控系统要实时统计当前井下人员的分布及井下人员的实时轨迹，需要实时对井下人员轨迹表进行访问，它的记录条数直接影响系统的效率，所以要对这个表进行合理的分流，使其数据量降到合适的范围，是我们设计时要考虑的问题。为了防止井下人员轨迹表单表的数据量过大，将这个大表拆分成小表以分散访问，以空间换取时间。将表中的记录按时间以月为单位进行分割，以月份命名。同时为了方便系统对每个工人的信息进行统计和考勤，并将当前在井下的人员信息保存到一个表中，称为实时表；对每个出井的人员把他的记录信息进行统计，生成一条历史记录，这个表包含人员姓名、卡号、入井时间、出井时间以及相应的班次，并把这条记录保存至以月份命名的历史表中。这样就能达到把一个大表分为多个小表的目的，降低了单表的数据量，并通过建立冗余表的方式提高了系统的执行效率。

3 结语

首先对井下人员定位系统的数据库进行概要设计，画出了系统的主要实体之间的E—R图；然后对井下人员定位系统数据库进行逻辑设计，建立了数据库中主要表结构；最后根据系统的特点对数据库的表进行了相应的优化设计，将大表拆分为小表以分散访问，达到以空间换时间的目的，提高系统的访问效率。所以在设计信息管理类系统时，应结合数据库设计规范及要求，同时也要根据系统的特点来合理地组织和设计数据库，达到二者之间的平衡，实现系统的设计目的。

参考文献：

[1]刘佳，朱慧，华钢.井下人员定位管理系统数据模型设计[J].工矿自动化，2013（7）：91-92

[2]陈小奎.井下人员定位管理系统数据库设计及优化[J].能源技术与管理，2007（6）：133-134.

数据库系统管理与优化论文 篇7

1 EGPRS优化数据管理系统功能

EGPRS优化数据管理系统实现EGPRS优化数据的自动采集和解析, 自动生成配置报表和性能报表。实现客户端和服务器 (B/S) 架构, 使用户只需登陆网页即可方便快捷地查看和下载所需EGPRS优化配置和性能报表。实现了智能诊断来定位EGPRS网络问题的功能, 自动统计EGPRS数据业务KPI指标TOP10、小区流量异常统计、小区扩容和RPP扩容的智能诊断等。用户查询数据后, 可以将查询结果以Excel表格形式保存到用户计算机。

2 技术实现方案

2.1 网络结构设计

本系统分为客户端和服务器两部分, 客户端即各地市的用户计算机, 服务器负责连接厂家操作维护子系统采集网络配置参数和EGPRS统计数据、解析统计数据、统计性能指标。客户端、服务器和厂家操作维护子系统间通过网管网相连。各地市用户通过用户计算机登录网管网, 通过用户名和密码即可访问系统, 系统的网络结构图如图1所示。

2.2 软件结构设计

本系统采用B/S的体系结构, 分为客户端和服务器两个部分, 服务器包括web服务器、数据库、爱立信统计数据/网络配置参数采集器、北电统计数据/网络配置参数采集器;客户端主要负责数据查询、智能诊断等功能。服务器端与客户端合理分工, 满足网络优化人员对数据业务指标、网络配置参数的查询分析需求。EGPRS优化数据管理系统将数据处理集中在服务器, 而用户只需登陆网页即可查看所需的信息。整个系统只需在机房搭建一台Web服务器和数据库服务器, 无需各地市各自搭建后台采集、存储、应用服务器。

2.3 设计实施

本系统服务器端使用的数据库是My SQL数据库, 服务器上开发数据采集和解析程序。由于数据来源分两个厂家北电和爱立信, 因此布置了两套数据采集和解析程序。数据采集和解析程序使用的Perl开发工具。上层应用程序使用Zend框架下PHP开发。

本系统的数据采集程序是重点, 分为爱立信数据采集和北电数据采集。根据各厂家操作维护子系统提供数据的特点, 爱立信设备的EGPRS业务统计数据以小时为周期采集, 为了保证数据完整性, 设置延迟两小时采集。由于网络配置参数的变化并不频繁, 设置采集周期为一天。北电设备的数据业务统计数据和网络配置参数数据每天采集一次。

2.3.1 爱立信数据业务统计数据的采集

爱立信OSS (操作维护子系统) 上CSDDB数据库存放有解析过的统计数据, 这些数据可以下载后直接使用, 但是由于解析原始文件需要有时间延迟, 这个数据库的数据的实时性较差, 另外, 下载这些数据也是需要厂家授权的。在爱立信的OSS上, 还可以取到原始的统计文件。爱立信原始统计数据由爱立信交换机定时上传到OSS上面, 格式与路径如下:

对于IOG网元路径为:/var/opt/ericsson/nms_eam_eac/data/fs/, 文件格式为:STFIOPFILE。

对于APG网元路径为:/var/opt/ericsson/sgw/outputfiles/apgfiles/sts/, 文件格式为:ASN.1。

本系统的数据采集程序是从OSS上下载原始统计文件, 解析程序对下载下来的原始统计文件进行解析, 入库至服务器上的My SQL数据库。河北移动的爱立信设备大部分为APG网元, 统计数据原始文件格式为ASN.1。根据3GPP ASN.1的规范编写了解析程序, 自动解析原始统计文件。

2.3.2 北电数据业务统计数据的采集

北电数据业务统计数据通过访问数据库的方式来采集。处理的数据涉及GSM/GPRS/EDGE Access Network, 原始性能数据首先产生于OMC-R/PCUOAM, 再传到SDO server。在现网中, 大部分OMC-R/PCUOAM/SDO Server是在同一硬件平台上实现。数据分为两大类:network和obs。其中:network为网络中各网元配置数据, 包含了网元的参数值;obs为性能数据, 包含了网元各个忙时的性能数据, 即Counter值。数据时间间隔由MD Scaner设置决定。数据首先进行预处理将omc上SDO目录下的network configuration和obs raw data FTP到服务器。自动检测obs raw data某BSC目录下的原始数据是否有与EGPRS有关的数据, 如果没有相关数据不进行下载。将network configuration和obs raw data分别进行数据格式解析转换后导入到数据库中。

3 结语

EGPRS优化数据管理系统在河北移动全省范围投入试运行以来, 逐步深入到河北移动日常的EGPRS网络优化工作中, 从根本上改变了河北移动EGPRS网络优化的工作流程, 简化了网络优化人员的工作程序, 提升了网络优化人员的工作效率和解决网络问题的速度。

摘要：EGPRS优化数据管理系统整合北电、爱立信厂家网管EGPRS数据, 通过智能诊断来定位EGPRS网络问题, 以展示EGPRS网络分布、流量和干扰情况, 可以拓展数据网络优化人员思路, 为移动EGPRS网络扩容、网络优化提供支撑。

关键词：EGPRS,智能诊断,数据优化,网络优化

参考文献

[1]韩斌杰.GPRS原理及其网络优化[M].机械工业出版社

[2]李荣.EDGE发展现状及存在问题分析[OL].www.cww.net.cn

[3]爱立信公司.爱立信GPRS网络评估及优化方案[R].

数据库系统管理与优化论文 篇8

据统计数据库应用系统的性能问题50%的情况下都是由于设计问题引起的。软件设计师在设计软件和数据库结构时, 未必能完全知道将来用户使用系统处理业务的各种复杂情况。这就造成在软件系统运行初始阶段只能发现个别的性能问题, 而其他的性能问题只能等到系统运行一段时间后才能暴露出来。针对这些问题, 我们提出数据库应用系统性能设计优化策略, 以提高数据应用子系统的性能。

1. 对数据库服务器内存分配的调整

由于对服务器内存参数的调整对oracle的性能影响显著, 它成为Oracle数据库性能调优的首选对象。服务器内存参数的调整主要是对数据库系统全局区的调整, 系统全局区包括共享池、数据缓冲区、日志缓冲区。其中最主要的是对数据缓冲区和共享池的参数调整。

数据库缓冲区的作用主要是将从磁盘中读取的数据块存放在内存缓存中, 从这个意义上说数据库缓冲区越大, 存放的共享数据就越多, 减少了对磁盘数据的物理读操作, 也就提高了系统的响应速度。

共享池的作用主要是用来存放最近使用过的sql语句的, 它由一个最近最少使用的算法来管理, 由库高速缓存和数据字典缓冲区两部分组成。修改这一参数的设置, 能提高系统性能, 是由Oracle数据库系统处理用户提交的SQL语句的步骤决定的。Oracle处理SQL语句, PL/SQL程序之前会先对其进行语法分析, 权限确认, 在确认语法正确, 权限合理的之后, 会对SQL进行优化, 最终生成执行计划。这个过程花费了大量的时间, 如果在执行这些语句的时候可以将这些内容保存下来, 在下次执行相同的SQL语句或者PL/SQL, 就可以跳过这个步骤, 进而提高系统的响应速度。一般来说, 系统内存为1G, 共享池可设为150M-200M, 内存增压1G, 该值增加100M, 但共享池的最大值不应当超过500M。综上所述, 系统全局区的参数设置应当随着系统的运行进行适当的调整, 使之在合理的范围内尽量大, 但是不能超过一个限度, 如果这一区域过大, 反而会占用操作系统使用的内存, 引起虚拟内存的页面交换, 降低了系统效率。

2. Sql优化

由于应用程序的执行最终归结为后台数据库中SQL语句的执行, SQL语句本身的执行效率就成为了影响oracle数据库执行效率的一个重要因素, 当我们对Oracle处理SQL语句的机制有所了解, 通过对SQL语句进行适当的调整, 就能提高Oracle数据库系统的性能。

1) 在基于规则的优化器中, Oracle对from子句中的表名是按照从右到左的顺序进行解析的, 即:From子句中排在最后的表会被首先处理。我们把这张表称做驱动表。当from字句中包含多个标的情况下, oracle是通过排序合并的方式连接这些表的, 为了提高oracle的执行效率, 应当选择包含记录条数少的表作为驱动表, 即放在from子句的最后。当from子句中有3张以上的表进行连接查询时, 需要将连接其他表的交叉表作为驱动表。

2) 在oracle语句中, where子句的执行顺序是自下而上的对语句进行解析的。为了提高sql语句的执行效率, 应该将能过滤掉大量数据的条件写在where子句的最后。

3) 在selcect语句中使用*虽然对编程人员简单方便, oracle会自动列出所有列名, 但oracle解析*时则是通过查询数据字典来完成对*的转换的, 这样耗费了更多的时间用来查询数据字典, 转换, 必然降低执行效率, 因此在selcect语句中应当直接列出所有的列名。

4) 用where子句代替having子句, 在where子句中排除不需要的记录, 这样的执行效率将远远高于执行完成之后用having子句对记录进行筛选。

总体来说, Oracle数据库的性能优化涉及的方面很广, 是一个系统工程, 需要在系统设计运行的过程中, 不断运用以上提到的各个方面, 对Oracle数据库系统进行优化, 以确保数据库的使用效率。数据库的性能变差, 往往不是一个方面的问题, 而是各种问题相互结合导致的, 因此, 需要对各种因素综合分析, 对各种优化手段综合应用, 才能做到将数据库的性能维持在一个比较好的水平。

3. 软件开发模式优化策略

3.1 避免访问回滚段

如果查询数据库时, 要访问的数据正被另外用户修改, 数据库为了维护读一致性, 需要访问会滚段来读取查询语句执行时刻的数据值。如果应用程序需要经常读取正在被其它用户修改的数据, 数据库系统为了得到一个数据, 不得不多次访问磁盘。数据库管理员可通过配置回滚段来减少查询时“snapshot tooold”错误的发生。解决这个问题的根本方法还是需要重新修改应用程序设计, 合理对事务进行划分。

3.2 表的分区和并行技术

如果必须要在数据库运行特别耗时的操作。应尽量地把这样的操作分解, 严格限制操作所涉及的记录数, 并设法使操作并行, 充分地提高执行效率。

(1) 使用分区。分区技术有两个潜在的好处:提高查询性能和提高数据库可用性。数据库查询时, 优化器知道那些分区包含查询所要的数据。而其它分区数据将不会被读取, 从而查询任务将更快完成。许多管理工作可在只一个分区上进行, 而不影响其它分区的数据。例如可以选择只删除一个表分区中的数据。可对表分区进行再分割, 把一个表分区迁移到不同的表空间上。可只对一个表分区进行分析统计。表分区的这些特性。

(2) 使用并行。Oracle数据库中几乎所有的操作都支持并行特性, 包括查询、插入、和数据加载。并行选项可以使多个处理器同时处理一条命令, 在创建库数据库对象时可以设定并行参数, 也可在查询语句中重新设。

4. 软件测试优化策略

许多情况下由于开发进度等原因, 软件性能压力测试都进行的不充分。这就导致软件产品交付时, 不能确保软件性能满足用户需求。这点常常被开发人员忽视。用户不仅需要软件能完成一定功能, 更需要软件能支撑自己业务的运行。因此应用软件性能不能满足业务处理的速度要求, 软件系统就需要优化。测试必须验证软件性能能否在希望负载情况下, 满足业务处理的速度要求。

(1) 用大量的数据进行测试。系统使用一段时间后, 数据库的性能会发生变化。例如oracle数据库一个表的pctfree和pctused参数设置可能会使数据块只有一半的空间被利用或使数据库记录链接 (chained) 。上面的情形都会引起数据库性能问题, 且只有在应用程序使用了一段时间后才能被发现。还有一个例子就是B_树索引, 随着数据的增加, 索引会在中心点分裂开来, 索引树次将增加新的层次, 这将会给数据添加造成负面影响。可以把B-树看成树, 树中的某些节点被存放在RAM中, 某些则不是。通常来说。根节点会被存放在RAM中, 叶节点则不是。事实上, 离根越远的节点越不可能被存放在RAM中。搜索数据时 (正如通过索引访问数据) , 对磁盘二级存储的一次访问至少要花费几个毫秒, 所以一个数据结构的性能, 高度依赖于从根到叶的路径上平均节点个数[6]:这个数目在B一树中叫做层次数。这也只有索引分裂后, 才会看出影响。应用程序正常工作了一两周的时间, 数据规模达到一个临界值后, 突然性能下降, 不能满足业务需要了。

(2) 足够多的用户并发测试。只有一个测试用户大多数情况下不能反映软件真实使用情况下的负载情况。我们必须测试在多个并发用户情况下是否会引起死锁 (deadlock) 以及性能下降等问题。例如两个软件模块以同样地方式向一个表中插入记录, 并查询该表的数据。如果这两个模块被同时使用, 这就会引起数据不一致的问题。只有经过多个用户的同时操作软件的测试, 这样的问题才可能被发现。

5. 总结

数据库应用系统的性能优化远不是按照厂家所列的有关指南通过短短的几步就可以达到的。要想获得最大的优化效果, 既需要具有广泛而深人的数据库原理和系统实践知识, 又要有扎实的应用程序设计能力, 同时要充分熟悉操作系统和有关的软硬件环境。笔者在实际工作中利用这些策略进行了数个数据库应用系统设计, 这些系统都表现出了良好的运行性能。

参考文献

[1]Gaja Krishna Vaidyanatha.Oracle性能优化技术内幕.机械工业出版社, 2002, 5:284.

数据库系统管理与优化论文 篇9

1 服务器端操作系统的优化配置

1) 服务器端操作系统配置是提升系统速度的前提。

为了提高Access数据库程序的速度, 程序运行所依赖的操作系统配置是决定速度效率的决定性因素。影响系统运行速度的主要在于操作系统配置要与应用系统相匹配。对Access数据库应用程序而言, 影响其性能的主要因素就是服务器端磁盘访问了。在执行程序过程中, 系统对物理磁盘的访问总是一个速度的瓶颈, 当然, 这是与访问存储在内存中的数据相比较而言。所以, 我们应该尽量减少对磁盘的访问频率。因为, 任何计算机应用程序总是要向一些磁盘存储器或其它外部存储设备调用数据信息, 因为这些存储器是应用系统的数据源, 所以, 我们的目标应该是保证所有的磁盘访问都尽可能有效。要实现这一点, 最便捷有效的方法是经常整理磁盘的数据碎片, 整理Access数据库所在的磁盘驱动器以及所有的数据源驱动器, 通过磁盘整理, 保持数据存储环境最大可能地优化, 从而保证磁盘访问高效快捷, 最大程度地减少在对物理磁盘进行读写而花费的时间, 虽然这些读写是不可避免的, 但优化的存储环境可以有效提高整个体系的性能和效率。

2) 调整缓冲区空间, 使内存最大化, 减少磁盘调用频率。

首先要增加操作系统的最大缓冲区的容量, 缓冲区的空间的大小, 涉及到系统最大缓冲区空间的设置。最大缓冲区的空间指的是Access信息管理系统作为内部存储空间而保留的内存空间。存储空间越大, 用户需求的数据能在内存中找到可能性越大, 同时减少了对物理磁盘的访问频率。Access信息管理系统需要的最小缓冲区是512KB, 如果计算机的硬件配置了大容量的内存, 完全可以为Access多分配一些供其使用的内存空间, 要调整内存配置, 只需要在windows目录下的Msaccess.Ini文件中增加对最大缓冲区的设置, 例如:使用文本编辑器中的记事本, 在Msaccess.Ini文件中找到[Option]字段, 在MaxBufferSize的等号后面添加一组数值, 就可以有效增加系统的缓冲区空间, 在这里, 这组数值就是为Access应用程序运行而重新分配的缓冲区空间数值。例如:设置MaxBufferSize=4048, 将为Access应用系统分配尽可能大的缓冲区空间。手动调节这个设置, 同时要让计算机硬件都能提供以下条件:a、不能妨碍用户同时正在运行的程序, b、不会影响其自身底层操作系统的运行效率。这样的内存空间的调整, 对Msaccess.Ini文件的修改将只能在下一次Access信息管理系统重新启动时生效, 而对当前运行的windows系统程序没有任何影响。

3) 限制系统自动加载Wizards, 提高内存利用率。

在默认状态下安装MicrosoftOffice时, 安装程序将自动安装多种Office向导和模板, 这些向导和模板在计算机开机后自动加载运行, 往往占用很多的内存空间, 对Access信息管理系统用户来说没有多大用处, 但却导致系统运行速度下降。为了释放更多内存空间供Access信息管理系统运行, 如果不经常调用向导和模板, 就没有必要加载Wizards。限制加载Wizards的路径是:打开MsAccess.Ini文件, 找到[libraries]字段, 在“wizards.mdb=ro”这一句之前加一个分号, 这样就避免了Wizards的自动加载。可以释放315B的内存给Access应用程序, 有效提高Access应用程序的性能, 同时可以使每个Office应用程序减少10秒启动时间。

2 Access后台数据库的程序优化

1) Access数据库的压缩修复。

应用系统管理员要经常性地压缩Access程序代码。Access后台数据库在使用过程中, 需要不断地增加和删除记录, 但是, Access不能自动释放被删除或更新的数据空间, 即使用户删除了一个记录, 而这个纪录仍然在数据库中占据着空间。压缩数据库就是将Access的这些冗余空间回收, 从而压缩数据库, 使其冗余降低。具体的验证结果是, 可以把数据查询的平均时间减少30%～50%, 从而实现对频繁调用和添加删除数据记录的数据库程序的压缩。为了压缩和修复Access数据库, 用户必须对该Access数据库具有“打开/运行”和“以独占方式打开”的权限。因此, 基于网络的Access后台数据库的压缩和修复时间最好选择在线用户最少的时段进行。具体的操作过程是打开Access数据库的“工具”菜单, 指向“数据库实用工具”, 然后单击“压缩和修复数据库”按钮, 系统即可自动完成压缩和修复。

2) 转换宏程序, 提高代码重用率。

在Access数据库系统开发过程中, 大多采用宏命令操作来搭建一个个应用程序模型, 拖拉式操作过程大大提高了系统开发效率。但在编程工作完成以后, 对宏集程序的优化是不可忽略的环节。一定要把所有的宏重新转换成VBA代码。这主要是因为Access代码要比宏运行得快。需要注意的是, 有三个宏操作不能转换成代码, 这三个宏是Autokeys、Autoexec和Addmenu, 在Access中没有相应的等价类, 因此可以采用调用BasicAutoexec函数的方法来优化这三个宏。创建共用代码模块是优化程序的最有效策略, Access后期优化中, 要将具有公用属性的VBA代码剔选出来, 存储为一个或一组共用模块, 在需要重复使用的“事件过程”中直接调用模块, 可以大大降低代码重复写入, 缩小数据库自身容量, 使程序最小化, 速率最大化。

3) 优化数据类型声明。

在代码中声明数据类型, 应力求简洁精确。例如对一个变量的类型声明, 如果不做自定义声明, Access缺省为可变类型, 虽然看似灵活自由, 但却浪费了内存资源。最为常用的类型声明中, checkBalance这个变量不需要超过4位小数精度, 只需将其定义为确定类型而不是可变类型。对过程函数的定义同样也可以如此操作。例如, 把函数PostCredit () 声明为整形, 而不是FunctionPostCredit () 。类型声明中需要注意的是, 如果估计一个变量将会被处理成一个空值, 那么要将其定义成为可变类型而不是精确的数据类型, 否则会出现验证错误。

4) 使用From/Report变量。

在Access程序开发中, 查询功能的实现是保证用户需求得到满足的重要条件, 多种条件下的查询功能, 也是评判一个Access数据库管理系统整体性能的技术指标。例如:如果要在代码中查阅一个名为[Net Price]的文本框, 可以使用Mytemprariable=Forms![CustomerInvoice][Netprice]!语句, 这条语句的执行过程是, Access首先在Forms对象里搜索名为[CustomerInvoice]的表, 一旦找到这张表, 接下来寻找名为[NetPrice]的控制程序, 并进行相应的操作。从这个例子可以看出, Access经过两次查询最终确定指定的控制程序。如果在同一程序 (函数或者子函数) 中再次查询[CustomerInvoice]表中任一控制, 完全可以删除会在下次出现的多余语句, 只需使用DimFasformSetF=Forms![CustomerInvoice]语句。以此避免Access每次查找[CustomerInvoice]表中的对象时, 都要把数据库的Form对象中全部搜索一遍。为了简化系统执行过程[NetPrice], 我们只需使用最简化的Mytempvariable=F![NetPrice]语句, 即可实现一个查询。

5) 调用windows函数代替VBA代码。

在Access各种控件属性中, 只要操作指令相关, 总是可以用一个windows函数调用来代替VBA代码执行同一个操作。函数调用和VBA代码之间最大的区别在于, 可以节省开发时间, 因为windows函数调用是已经完成编码并经过优化, 同时也因为它们是用C语言编写的机器直接执行语言, 而VBA代码则要通过编译才能被执行, 并且需要在执行时一行一行地解释。例如, 一个最普通的例子是custom.ini设置。常用办法是使用函数得到一个文件指针, 打开文件, 读/写文件, 然后关闭它。实际上, 完全可以简单地使用GetPrivateProfileString和WritePrivateProfileString函数来实现这个操作过程, 其运行快捷并且已经编码优化, 既然随手可用的函数可以大大简化系统的操作, 就没有必要墨守成规地一步一行地进行繁琐重复的程序执行过程。

总之, 基于网络环境下的Access数据库系统, 随着系统使用周期的不断延长, 对系统的日常管理维护, 是保证系统稳定、高效运行的不容忽视的工作。随着Access版本的升级, 其原有的许多技术性缺陷必将得到不断地完善, 为了保证在线用户的需求, 应用系统也要不断升级, 始终保持技术平台的前沿性和系统运行的高效率, 需要系统管理人员不断地探索和追求。

摘要：Access因其功能完善, 结构集成, 界面友好等优势被许多网站或自动化办公系统用作后台数据库。但其作为网络信息管理系统数据库时, 存在着资源占用率高, 信息冗余量大, 运行速度低等缺陷, 如何克服这些缺陷, 是系统日常管理和维护中不容忽视的技术环节。

关键词：Access数据库,系统配置,程序优化

参考文献

[1]周国民.数据库项目开发实践.北京:中国铁道出版社[M].2005:127-130.

[2]章立民.Access2003高手攻略.北京:中国铁道出版社[M].2004:24-29.

[3]萨师煊, 王珊.数据库系统概论.北京:高等教育出版社[M].1999:96-98.

数据库系统管理与优化论文 篇10

装置操作卡管理系统经过一年多的正式运行, 近期, 车间的用户普遍反映运行速度比较慢。用普通用户进行测试, 结果如下:从登录界面输入正确的用户名和密码后, 到显示出系统的主界面的时间间隔大约25~35秒;而操作卡查询后, 点击某个查询出来的操作卡, 到显示该操作卡的详细内容的时间间隔大约30~40秒。分析操作卡系统的数据量和用户的使用频率, 这样的运行速度确实很慢, 可以说给用户的操作带来了不便, 影响了工作效率。

2. 速度慢的原因分析

问题很普遍, 显然不是某台客户机的问题, 而且在配置较好的客户机上测试, 访问速度也很慢, 配置较低的客户机, 其访问速度就可想而知了。经过分析, 很可能与以下几个方面的原因有关:服务器的配置低;当前表中的数据量过大;数据库的参数配置不合理;这些都是系统运行速度的瓶颈。当然, 网络状况和病毒也是影响系统运行速度的原因, 需要一一排查。

3. 网络状况和病毒的排查

目前分公司的信息系统很多, 通过对照分析, 同操作卡系统情况类似的MES系统的运行速度在正常范围内, 这两个系统同在一个网段, 可以排除网络原因;系统服务器上的防病毒软件“赛门铁克”, 没有病毒隔离报警, 而且用各种病毒专杀工具进行杀毒, 没有查出病毒, 可以排出病毒原因。

4. 系统服务器的配置

操作卡系统的服务器配置如下:

服务器型号:DELL POWEREDGE 2850

CPU:3G双CPU

内存:3G

硬盘:5块146G的SCSI硬盘, 共700G, 做RAID5后, 剩余550G。

对于以上配置的服务器, 运行功能相对简单、数据交换量不大的操作卡系统, 还是绰绰有余的。

5. 当前表中的数据量过大影响系统运行速度

5.1 当前表的数据统计

操作卡系统用来存储数据的后台数据库是ORACLE数据库, 系统主界面打开时需要调用多个表中的记录, 其中有两个表中的数据量较大, 一个是OPER_DAILYOPERHEAD, 一个是OPER_DAILYOPERDETAIL。截止到6月底, 表OPER_DAILYOPERHEAD中的记录个数为86406条, 而表OPER_DAILYOPERDETAIL中的数据相对要多些, 达到2336979条记录, 导出的数据库文件大约有25G左右。对于oracle数据库来说, 表中的记录数量还没有达到影响系统运行速度的限额, 但是考虑到数据量还在不断的增加, 削除因当前表记录过多影响读取速度的因素, 决定把当前表中的大部分数据转移到历史备份表中, 以提高系统的运行速度。

5.2 历史数据转移

起初, 系统设计时没有考虑到历史数据转移功能, 随着当前表中的数据量逐渐增加, 如果不转移数据, 在进行数据查询的时候, 会越来越慢, 最终肯定会影响系统的运行速度。

可以根据实际情况选择数据转移的起始时间和截止时间, 为了避免转移的数据量过大而影响系统当前的运行速度, 以时间间隔半个月为宜。通过与生产处技术人员交流, 当前表中可以只保留2个月的最新数据, 其余的都作为历史数据转移到历史数据表中。对于用户来说, 数据转移后所有操作不受任何影响。

通过测试, 历史数据转移后, 系统的运行速度同预期效果一样, 虽然有所提升, 但不明显, 只是提高了几秒钟。同时也说明了, 目前表中的数据量还不是影响系统运行速度的关键因素。

6. oracle数据库优化

数据库的优化是改进Oracle数据库性能的有效的方法之一。

为了访问数据库中的数据, Oracle数据库为所有用户提供一组后台进程, 并且, 有一些存储结构专门用来存储最近的有关对数据库访问的数据。这些存储区域可以通过减少对数据库文件的I/O次数来改善数据库性能。数据库系统的执行效率较低时, 就要对Oracle数据库的参数进行调整, 以便提高Oracle数据库性能。

O r a c l e 9 i在安装时为每个数据库建立了一个P f i l e, P f i l e (Parameter File, 参数文件) 文件是基于文本格式的参数文件, 含有数据库的配置参数, 默认的名称为“init+例程名.ora”, 这是一个文本文件, 可以用任何文本编辑工具打开。

检查参数配置文件的内容发现, 以下参数设置不太合理, 并适当的进行了调整:

*.db_cache_size=25165824:数据缓冲区大小;改为1288490189。该值越大, 可以减少对数据库文件的I/O次数, 提高运行效率。

*.p g a_a g g r e g a t e_t a r g e t=2 5 1 6 5 8 2 4:P G A目标值;改为262144000。使用PGA_AGGREGATE_TARGET设置整个PGA大小, Oracle将为每个Session按照实际需要为其分配PGA, 并尽量维持PGA总量不超过PGA_AGGREGATE_TARGET值。

*.shared_pool_size=50331648:共享池大小;改为209715200。用于存储共享游标、存储的过程、控制结构和并行执行消息缓冲区等对象, 较大的值能改善多用户系统的性能。

*.sort_area_size=524288:排序区使用的最大内存量。改为1048576。排序完成后, 各行将返回, 并且内存将释放。增大该值可以提高大型排序的效率。

7. 创建ORACLE索引表

Oracle数据库中, 标准表和索引表的本职区别在于:索引表中的ROWID列存放的是主键信息, 是逻辑的物理地址;而在标准表的ROWID伪列中则存储的是真实的物理地址。

Oracle数据库索引表的优势主要体现在数据查询上, 而且, 这个优势是非常明显的。一是索引表能够获得比标准表更快的查询速度;二是索引表中的记录, 是按照主键列进行排序存储的;三是利用溢出存储功能, 提高常用列的访问速度。索引表减少了数据查询过程中的中间环节, 避免了额外的数据块读取操作, 可以获得更快的查询速度。

如果数据表的变更比较频繁的话, 则不适合采用索引表。这主要是因为Oracle数据库在对索引表管理时, 开销比较大。另一种方法是在基本表上建立索引, 这样虽然查询效果没有索引表那么好, 但是, 却可以大大减少Oracle数据库的开销。

建立索引要注意:一是在索引表中, 不能对非主键建立索引。这是索引表建立的一个限制条件, 数据库管理人员必须无条件的遵守。二是必须给索引表建立主键。有些数据库管理员有个习惯, 在建立表的时候, 一开始不设置主键。等到表维护的时候, 再确定某个字段作为主键。但是, 在索引表建立的时候, 一开始就要指定表的主键, 否则的话, 会有错误产生。这也是数据库管理人员需要注意的。

8. 测试

系统源程序及Oracle数据库参数优化后, 经过多用户多次测试, 反馈的结果是:

从登录界面输入正确的用户名和密码后, 到显示出系统的主界面的时间间隔大约5秒左右;而操作卡查询后, 点击某个查询出来的操作卡, 到显示该操作卡的详细内容的时间间隔大约10秒以内。

由此说明, oracle数据库的性能优化对提高操作卡系统的运行速度起到了关键作用。

9. 结语

为了保证Oracle数据库运行在最佳的性能状态下, 在信息系统开发之前就应该考虑数据库的优化策略。优化策略一般包括服务器操作系统参数调整、数据库参数调整、网络性能调整、应用程序SQL语句分析及设计等几个方面。但是数据库的性能优化调整是一个系统工程, 涉及的方面很多。在实际工作中, 还要根据用户反映的具体情况, 认真分析Oracle在运行过程当中出现的各种问题, 以保证Oracle数据库运行的高效率, 保证用户的正常使用。

摘要：本文介绍了装置操作卡管理系统的运行速度快慢与数据库优化的密切关系, 分析了系统运行速度慢的原因, 阐述了提升系统运行速度的解决办法, 介绍了oracle数据库的参数配置, 阐明了优化数据库是提升系统运行速度的关键所在。

关键词：操作卡,运行速度,数据库优化

参考文献

[1]北京华创操作卡系统安装与配置手册

ERP系统主数据的维护与管理 篇11

【关键词】主数据；维护；管理

1、概述

任何企业ERP项目的运行，都是架构在数据的坚实基础上。有了正确的数据ERP系统才能够将信息传播到整个企业，在企业层次上去优化各种业务工作，提高管理水平。数据是ERP系统运行的基础，只有确保数据的准确性、维护的及时性和严谨性，才能保证ERP系统的正常运行。

“数据”是科学实验、检验、统计等所获得的和用于科学研究、技术设计、查证、决策等的数值。ERP系统主数据又称参照数据，是由定义业务实体的事实构成，事实被用于对一个实体建立多个定义或视图。维护主数据包括物料主数据、供应商、客户、会计科目视图等，主数据字段繁、种类多、相互制约的特点决定了主数据的维护一定要非常重视并投入充分的力量和资源才能解决。

ERP（enterprise resource planning）企业资源计划，它是将企业内部所有资源整合在一起，对采购、生产、成本、库存、分销、财务资源进行规划，从而达到最佳资源组合，取得最佳效益。数据是这些资源的表现形式，任何经营管理活动都离不开对这些数据的存取，所以说数据是企业的一种无形资产。因此，在ERP项目运行过程中，重中之重就是数据的维护和管理。

2、主数据的维护

主数据在维护过程中要高度重视主数据维护的准确性，保证数据维护的及时性和严谨性，ERP系统才能正常的运行。不准确的数据对于无辜的计算机来说其实就是谎言，它们只能被计算机用来高速地产生错误的答案。只有保证每一次数据维护的准确，才能保证系统数据的准确。

主数据字段繁、种类多、相互制约的特点，使得主数据的维护必须确保及时性和严谨性。为确保主数据维护的及时性和严谨性，我们制定各项标准化规范。大到信息指标体系、信息交换接口要标准化，小到分类编码、文档编写、字段定义及维护流程同样也要标准规范化。确保在最短的时间内能够进行数据准确维护，使数据的维护进行规范处理。

主数据维护方法有直接输入法和批量导入法。直接输入法使用ERP系统事物代码，对视图中的各项目进行录入，这种方法适合少量数据的维护，由于是手工更改，出错的概率较高。主数据的维护既是日常性的工作，也会有阶段性的工作。往往阶段性的工作采用大数据量的批量更改，如价格调整、类别调整等等，因此，系统要有批量处理和调整的功能。批量导入法使用批导程序，一次执行大批量的更改，但要求数据维护人员按照用户提供的数据模板正确导入ERP系统中。

真正做好主数据维护和管理工作，要求主数据维护人员在实际中做好以下几方面工作。

2.1 注重业务流程及其功能改变

由于ERP系统主数据的关键字段是与业务流程及其功能息息相关的，所以在维护主数据时必须关注系统内业务流程设计及其功能变化。在系统运行过程中，系统功能会被优化或改进。这时，通常会对主数据的维护提出新要求。主数据维护人员必须关注这些变化，确保主数据随时更改。因此，从管理上要求在系统设计、配置发生变化时，各模块程序维护和开发人员要及时和主数据维护人员沟通，而主数据人员一定要将这些转化为主数据具体维护要求。

2.2 强化ERP项目相关模块原理的培训

要求主数据维护人员吃透ERP精神，根据系统中的原理和做法，具体应用到实际工作中去，做精、做好，将数据和业务流程紧密结合，重要的是知道数据怎么做，更知道为什么这么做，以达到培训的最佳效果。

2.3 掌握批导程序的制作方法

数据批量导入是主数据维护的一项重要技能。常用的批导程序通常是在上线初期就由开发人员准备好的，可是日常维护过程中，时常会有新的批导入任务，这就要求主数据维护人员不仅能够熟练地使用现有的批导程序以保证导人数据的正确，而且还需要掌握批导程序的制作方法，以适应生产变化的要求。

2.4 建立主数据发布制度，确保主数据与各项系统外业务的衔接

主数据维护完成后，并不意味着主数据维护流程已经结束。如系统内新增了材料主数据，有了新的物料编码，除设计人员与采购人员知道外，还应在主数据维护流程中增加主数据信息发布这一环节，明确主数据发布的时间、地点、发布的部门、发布范围、如何发布等，并建立企业主数据发布制度。经过了这样的调整，业务部门对新增主数据的用途不再有疑惑，而且可以及时地做出业务反应。

2.5 预见性的维护物料主数据

预见性的维护物料主数据，适应生产的变化，带钢的生产品种规格在成品中数量最大，通过实际工作总结，在维护XG08D2时，同时维护Q195。同样在维护Q235时，同时维护Q215，这样即能适应生产过程中的对物料编码的需求，又提高物料主数据维护的效率。

3、主数据的管理

ERP数据管理体系是通过多次研讨分析，经过较长时间的实践和改进逐步完善建立起来的，目前，基本形成了较为完善的管理体系。

3.1 完善物料主数据维护流程

ERP实施期间由数据组制定产成品、半成品、原料、材料、备品备件、供应商数据收集管理办法和流程，进行数据的收集整理和维护。甩物料帐后，ERP项目部成立运营监管小组负责ERP系统静态数据和数据故障的管理，对静态数据和动态数据维护、变更、修改业务进行受理、审批、备案，并通知责任单位进行处理等；负责动态数据的监控、备案等；按制度执行考核。

3.2 采用技术手段完善管理

对于几十万个物料数据，新增物料只靠单一通过加强管理来杜绝描述重复还是不够的，我们还编写许多有关数据管理方面的程序，来检查数据维护的合法性和完整性，并开发了一个模糊查询程序，有效地控制了描述重复。在新增物料前要对新增物料描述进行查重检查，查找过程中对物料描述数据格式进行转换，如：大小写、全角半角等自动转换对比。

4、结语

数据库系统管理与优化论文 篇12

随着信息化建设的不断推进以及信息技术的快速发展,为适应多元化业务发展需要,多个业务系统随之建设,产生了大量的以不同方式存储、依赖于不同数据库管理系统的数据。例如业务数据分别存储在SQL Server,Oracle数据库中[1],在这些异构数据库[2]平台上运行着业务相关的多种应用系统。如何在不影响现有系统运行的前提下,最大限度地利用信息资源,避免重复开发,必须解决异构数据库的统一操作问题。如何快速有效地采集异构数据库中的信息,建立综合信息资源库,实现数据共享,是本文需要解决的问题之一。另外,面对综合信息资源库中的大量数据,怎样在业务应用中实现快速、有效、全面的检索效果,提高数据的利用性,也是本文需要解决的另一问题。

本文围绕基于J2EE技术架构的多个业务应用系统开展研究,其信息来源十分广泛,包括现有的业务管理系统、文件系统、文档资料等。而各个系统的数据存储方式、存储结构、数据库类型均不相同,如何在异构的存储环境下实现稳定可靠的数据共享和数据采集是本文设计的要点之一。同时,业务数据涵盖日常应用中的所有资料、文档等信息,信息类型复杂多样,包括结构化信息、非结构化信息、文件(DOC,PDF,txt,Excel,HTML)等多种格式。系统数据量随着日积月累会越来越大,要在这样大量复杂的数据中实现对多种类型信息的高效准确检索也是本文设计的另一要点。

基于上述分析,本文采用了Oracle数据库的Oracle Transparent Gateway[3,4],Oracle Text[5,6]等技术。在设计采集检索功能时,不仅要满足异构数据库环境下数据的实时采集和共享,还要支持权限控制[7,8]下对多种类型、多种格式文件内容的高效检索。

1 数据采集与全文检索方案设计与实现

1.1 系统框架设计

在Oracle Transparent Gateway,Oracle Text组件的基础上,结合权限控制,本系统实现了高效简洁的数据采集与全文检索功能,系统框架设计如图1 所示。

系统数据来源于异构SQL Server数据库、Excel文件和本系统的文档资料。针对不同数据源,SQL Server数据库采用“采集—处理—导入”的数据层集成方式,实现了异构数据向本系统数据库的迁移,Excel文件和本系统的文档资料通过导入、手工录入方式将资料信息装载入库,自动建立全文信息索引,为实现全文检索奠定基础。全文检索建立于权限控制体制之上,首先由用户提出检索请求,待全文检索模块处理后进入综合信息库进行关键词检索,之后将检索匹配的结果传递给权限审核模块,然后在检索记录中过滤出可供用户查阅的信息,并将过滤后的信息经检索结果处理模块处理后存储于用户临时存储区供用户浏览查询。用户浏览资料详情时,必须同时具备对资料所属目录的查看权限和对资料的查看权限才能查看资料。

1.2 系统实现

(1)数据库设计

综合考虑系统采集检索需求,需要采集的数据类型包含数字、字符、日期、文本等,需要检索的资料信息分为三类:字符类型(varchar2)、大文本类型(clob)、非结构化blob类型数据(DOC,PDF,txt,Excel,HTML)。数据库设计采用了反规范化设计方式,需要检索的资料信息按其数据类型分别存储在三张表:资料内容1、资料内容2、资料内容3 中,每张表中均用记录ID、资料类型ID、资料表ID、资料表记录的ID、资料表记录的字段ID进行关联。系统资料与权限管理的数据库设计见图2。

(2)数据采集与存储

系统的数据来源主要有三部分:采集日报资料、导入重点资料和现行文档资料。日报资料来源于基于SQL Server平台的管理系统,系统采用Oracle Transpar⁃ent Gateway实现与SQL Server的无缝连接,采取“采集—处理—导入”的数据层集成方式,实现了异构数据向本系统数据库的迁移;重点资料为系统用户批量导入的Excel信息;现行文档为DOC,PDF,txt,Excel,HTML等格式的文档资料。重点资料的批量导入和文档资料的手工录入在应用层实现。日报资料的采集是在数据层采用Oracle Transparent Gateway连接SQL Server,由PL/SQL编程实现。Oracle Transparent Gateway的采集过程见图3。

在采集服务器上安装Oracle Transparent Gateway for SQL Server,完成配置透明网关相关参数、listener.ora、tnsnames.ora。在Oracle端创建链接SQL Server数据库的database link,发出查询需求,SQL Server通过Transparent Gateway识别出Oracle端发出的查询需求,获取查询结果记录集,记录类型主要包括数字、字符、日期、文本等,Transparent Gateway将记录集数据转换为与Oracle兼容的数据,并返回给Oracle服务器,存储在临时表中。通过临时表上的行级触发器将不同字段类型的数据导入到对应的信息资料表中。

(3)创建索引和索引同步

系统采用CONTEXT类型索引,它支持并行检索方式,在创建本地CONTEXT索引时,需要设置并行度和系统资源属性。在执行检索任务时,并行协调器依据创建索引时设置的并行度和系统资源属性调用多个从属进程对全文索引进行并行检索。每个从属进程对应于全文检索的一个或多个分区,当检索任务完成后,协调器负责将各个检索结果进行汇总并传递给用户。本系统分别对资料内容1、资料内容2、资料内容3 的“存储字符”、“存储大文本”、“存储二进制文件路径”创建并行分区全文索引。

本系统在创建全文索引的同时采用了索引同步机制,原因是当资料内容1、资料内容2、资料内容3 表中发生DML操作后,基表上对应的全文索引不会自动更新,需要手动对其更新,在此之前是不能检索到基表中的新内容,因此需要调用CTX_DDL.SYNC_INDEX存储过程手动同步索引。

(4)检索存储过程

为实现文档信息的全文检索和权限过滤,本文的检索存储过程采用了如下核心SQL语句:

2 系统优化

为了提高数据库性能,加快应用系统的检索速度,系统采用了以下方法进行优化。

2.1 采用分区表技术

系统在设计资料内容1、资料内容2、资料内容3 时采用了按范围分区的分区表技术[9⁃11],可以将大表分成多个存储单元,避免了系统资料信息表作为一个大的、单独的对象进行管理,提高了大量数据的伸缩性。

通过采用分区表技术,实现了对资料信息表的多分区管理,每个分区对应一个小的存储单元,每个存储单元可以单独操作管理。检索时采用多分区并行处理技术,减少时间开支,提高执行效率,还可通过采用屏蔽故障分区技术,确保数据检索的可靠性。

2.2 优化检索响应时间

在大规模数据检索过程中,用户期望在最短时间内看到检索结果,可采用快速返回前几条检索结果的方式显示给用户。在编写查询语句时加入FIRST_ROWS提示,可以使查询优化器以较快的查询速度将前几条检索结果传递给用户,避免了在整个查询任务结束后方能浏览检索结果的局限性,满足了用户快速检索的需求。

另外本系统在创建CONTEXT索引时采用了索引分区技术,为分区表创建相应的分区索引。这样在检索过程中,只需要检索相关的分区,特别是对于分区键列上的范围搜索和排序,可避免全表扫描过程,能够显著缩短检索响应时间。

2.3 定时优化全文索引

全文检索对象所在的基表经DML操作后,其相应的全文索引不会自动更新,有必要采用全文索引同步机制。同时频繁的索引同步操作会导致索引的碎片,过多的碎片会降低检索的效率,因此,需要对全文索引进行优化。

例如资料信息中包含关键词“优化”的文档有doc2,doc6,doc7,当含有关键词“优化”的doc8 被存储之后,倒排索引会单独为doc8 文档创建一条索引条目,从而产生了碎片。系统采用CTX_DDL.OPTIMIZE_INDEX存储过程对索引进行优化,可以避免碎片的产生,由于系统创建CONTEXT索引采用了分区索引技术,因此需要对每个分区进行索引优化。Oracle Text仅提供了一种手动索引优化方式,本系统采用dbms_scheduler调度的create_job创建作业,可定时自动优化全文索引。

2.4 定期维护统计信息

在Oracle较新版本中查询优化器采用了改进的CBO(基于成本的优化器)[12],根据收集的系统统计信息和对象统计信息对查询计划成本进行计算,最终实施选用最低成本的查询计划。这就需要对系统统计信息和对象统计信息进行实时更新,以确保CBO有良好执行计划。为获取最新系统统计信息和对象统计信息,系统将收集表统计信息过程DBMS_STATS.GATHER_TA⁃BLE_STATS和收集索引统计信息过程DBMS_STATS.GATHER_INDEX_STATS写入Oracle的自动维护作业中,定期自动执行,确保统计信息的实时更新。

2.5 存储优化

若将blob格式的数据存储在数据库中,随着数据量的增大,将导致全文索引的膨胀率随之增大,不仅占用较大的存储空间,增加管理维护难度,而且还会影响I/O效率。为此,系统采用了将blob格式(DOC,PDF,txt,Excel,HTML)数据存储在外部专用存储设备上的存储方式,使Oracle Text以FILE_DATASTORE方式进行数据访问。另外采用了Oracle的ASM(自动存储管理机制)以优化I/O资源实现负载均衡。通过创建ASM实例,系统可以自动将数据均匀地存储在不同通道的不同磁盘上,实现I/O请求的均匀化,并将对文件的操作改为对磁盘组的操作,可显著提高I/O性能。

3 系统测试分析

系统开发完成后,重点对检索速度和查准率进行了测试,测试过程如下:对于检索速度的测试,采用Ora⁃cle Text对1 000 个Word,PDF格式文档循环插入生成的50 万条记录进行了查询时间测试;对于查准率的测试,分别用微软和Adobe的搜索工具对1 000 个Word和PDF文档进行10 组关键词的检索,两者的检索结果合并后作为基准,与Oracle Text全文检索结果进行比较,以确定Oracle Text检索功能的准确性。

系统测试环境中戴尔R720 服务器CPU为2×4 核E5620 2.4 GHz,内存为12 GB,操作系统为redhat 5.5Linux,Oracle数据库版本为Oracle 11g R2 11.2.0.4。选取50 万条文档资料作为测试对象,在1 000,10 000,100 000,200 000,500 000 条数据规模下对Oracle Text检索分别进行了20 次测试,取其平均值作为测试结果,结果如表1 所示。

测试结果表明:数据库表中的记录在50 万数据量级的测试条件下,Oracle Text的检索响应时间小于1 s,平均查准率为88%,可以满足用户需求。

4 结语

本文采用Oracle Transparent Gateway,Oracle Text等关键技术,结合权限控制,给出了应用系统数据采集与全文检索的方案设计与优化。该方案具有运行效率高、简单快捷等优点,可以有效地采集业务系统中的异构信息资源,提供对多种类型、多种文件格式内容的高效检索。

从该方案应用前景来看,其异构数据库采集功能较强,不仅支持SQL Server数据库,还可扩展至Sybase,DB2等数据库。

参考文献

[1]魏永丰,刘立月.异构数据库系统中的Oracle与SQL Server数据共享技术[J].华东交通大学学报,2005,22(1):92-94.

[2]郭东恩,沈燕.Oracle透明网关技术实现异构数据库互连[J].电脑开发与应用,2008,21(9):58-59.

[3]蓝永健.利用Oracle透明网关技术进行系统整合的研究[J].广东第二师范学院学报,2008,28(5):92-96.

[4]Oracle Corporation.Oracle 11g database documentation:gate-way for SQL server user’s guide,11g release 2[R].Califor-nia,USA:Oracle Corporation,2009.

[5]Oracle Corporation.Oracle 11g database documentation:textapplication developer’s guide 11g Release 2[R].California,USA:Oracle Corporation,2009.

[6]Oracle Corporation.Oracle 11g a documentation:text reference[R].California,USA:Oracle Corporation,2009.

[7]熊志辉,王德鑫,王炜,等.基于Oracle的多权限多格式文档组织与检索系统[J].计算机应用,2008,28(9):2407-2409.

[8]朱松岩,叶华平,李生林,等.基于多层授权体制的档案全文检索系统设计与实现[J].后勤工程学院学报,2005,21(1):57⁃60.

[9]李瑞丽,钱皓,黄以凯.基于Oracle大数据的全文检索技术研究与实现[J].微型电脑应用,2013,29(1):18⁃21.

[10]李尚初.Oracle的全文检索技术[J].哈尔滨师范大学自然科学学报,2009,25(4):92⁃95.

[11]Oracle Corporation.Oracle 11g database documentation:per⁃formance tuning guide[R].California,USA:Oracle Corpora⁃tion,2009.