四点数据库开发技术分析.docx

四点数据库开发技术分析.docx

《四点数据库开发技术分析.docx》由会员分享，可在线阅读，更多相关《四点数据库开发技术分析.docx（8页珍藏版）》请在冰豆网上搜索。

四点数据库开发技术分析

解析四点数据库开发技术

数据库的应用特不广泛，在生产生活或上网娱乐过程中，都离不开数据库。

数据库是存放数据的仓库，在那个仓库里面，数据库的使用者能够专门方便的集中治理数据。

当今常用的几种数据库治理系统DBMS　　

计算机实质上确实是“信息处理机”，所谓的信息包括：

文字、图片、音频和视频等一切具有特定意义的符号或记录。

而计算机从诞生之日起就要跟这些数据打交道，最初的数据治理系统称为“文件系统”，立即数据以文件列表的方式存放，后来为了让数据治理规范化，开发了数据库治理系常DBMS）。

与数据库知识相关的一些差不多概念有：

数据：

文字、图片、音频和视频等一切具有特定意义的符号或记录。

数据库：

也称为数据仓库，是存放数据的物理的或逻辑的介质。

数据库治理系统（DBMS）：

治理数据库的专用数据治理软件。

数据库治理员（DBA）：

具有治理数据库权限的人。

依照功能级不和数据治理性能，当今常用的数据库治理系统（DBMS）能够分为3类：

大型数据库：

Oracle、DB2。

中大型数据库：

Sybase、Informix、SqlServer。

小型数据库：

Access、Sybasesql、Anywhere、dbf、execl。

关系代数与数据库SQL语言　　

当今主流的数据库差不多上属于“关系型数据库”，所谓关系型数据库确实是数据库里面治理的数据确实是一张二维表　　

规范化和数据库表设计常见的问题　　

如前文所述，一个主码就能够确定一个元组，也确实是讲元组的所有属性都依靠于主码，假如A属性组函数依靠于B属性组，同时B属性组假如去掉任一属性，则函数依靠都不成立，则成为A属性组完全函数依靠于B属性组。

完全函数依靠在数据库设计规范化理论中有重要的意义。

目前关系数据库有六种范式：

第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、第四范式（4NF）、第五范式（5NF）和第六范式（6NF）。

满足最低要求的范式是第一范式（1NF）。

在第一范式的基础上进一步满足更多要求的称为第二范式（2NF），其余范式以次类推。

反过来讲，也确实是满足6NF的，一定满足5NF，以此类推。

ODBC、DAO和ADO技术简介　　

如前文所述，序列化实际上确实是将要保存的数据在程序关闭之前写入磁盘，而需要读取时，再从磁盘写入到内存中进行处理，显然，假如要处理的数据比系统可用的内存大（系统可用的内存能够由物理内存和虚拟内存组成），则序列化是无效的。

另外，就确实是待处理的数据能够顺利装入内存，也没有必要将所有的数据都装入内存处理。

微软公司的ADO（ActiveXDataObjects）是一个用于存取数据源的COM组件。

它提供了编程语言和统一数据访问方式OLEDB的一个中间层。

同意开发人员编写访问数据的代码而不用关怀数据库是如何实现的，而只用关怀到数据库的连接。

访问数据库的时候，关于SQL的知识不是必要的，然而特定数据库支持的SQL命令仍能够通过ADO中的命令对象来执行。

数据库性能优化之CPU资源

数据库优化不仅仅是DBA（数据库治理员）的情况，它也是应用设计人员、应用开发人员必须作的情况。

在确认了由谁来进行数据库优化之后，就要考虑从何时开始进行数据库优化。

许多人认为对数据库的优化不急，等到用户开始抱怨系统运行速度无法忍受时，再进行优化。

但现在某些有效的优化手段己无法有效的使用。

关于熟悉软件工程的人来讲，在一个系统的生命周期内，对系统进行调整，想利用较小的人力、物力而能够收到较好的收益的话，最好在系统的设计和开发期内进行。

假如软件已成为产品，现在再进行系统调整，则耗费的精力最多，而收益最小。

同样，关于数据库的优化，最好的时期是在系统的设计和开发时期，尽量幸免在系统成型之后再进行优化。

不管是设计或维护数据库系统，都必须建立专门的性能指标，使人们能够有明确的目标，明白在何时进行调整。

调整一个数据库系统的最有效的步骤如下：

1、在设计系统时考虑系统的性能。

2、在开发应用程序时考虑系统的性能。

3、调整操作系统的硬件和软件设置。

4、识不系统的性能的瓶颈。

5、确认问题的缘故。

6、采取纠正的动作　　

关于任何一个系统而言，良好设计的系统能够防止在应用生命周期以后产生的性能问题。

同时，每一个系统设计人员和应用开发人员必须了解Oracle的查询处理机制来编写有效的SQL语句。

以下提出进行系统设计时，应尽量遵循的原则：

1、消除客户机/服务器应用中不必要的网络传输。

例如：

使用Oracle的REPORT时，尽可能对单表进行处理，不要对多表进行连接处理，以免造成不必要的网络传输。

2、使用适用于自己系统的相应的Oracle服务器选件（例如：

并行查询或分布式数据库等）。

3、除非系统有专门的需要，请使用缺省的Oracle锁，无须自己对应用程序进行加锁处理，以免产生不可预测的错误。

4、为了便于对数据库的每个应用进行跟踪调测，尽可能记住每一个用户所运行的模块。

便于今后对系统性能的跟踪。

5、在数据库建立时，需从自身的实际动身建立合适的数据块长度。

CPU是服务器的一项重要资源，服务器良好的工作状态是在工作高峰时CPU的使用率在90%以上。

假如空闲时刻CPU使用率就在90%以上，讲明服务器缺乏CPU资源，假如工作高峰时CPU使用率仍然专门低，讲明服务器CPU资源还比较富余。

使用操作系统命令能够看到CPU的使用情况，一般UNIX操作系统的服务器，能够使用sar-u命令查看CPU的使用率，Windows系列的操作系统的服务器，能够使用性能治理器来查看CPU的使用率。

数据库治理员能够通过查看v$sysstat数据字典中“CPUusedbythissession”统计项得知Oracle数据库使用的CPU时刻，查看“OSUserlevelCPUtime”统计项得知操作系统用户态下的CPU时刻，查看“OSSystemcallCPUtime”统计项得知操作系统系统态下的CPU时刻，操作系统总的CPU时刻确实是用户态和系统态时刻之和，假如Oracle数据库使用的CPU时刻占操作系统总的CPU时刻90%以上，讲明服务器CPU差不多上被Oracle数据库使用着，这是合理，反之，讲明服务器CPU被其它程序占用过多，Oracle数据库无法得到更多的CPU时刻。

数据库治理员还能够通过查看v$sesstat数据字典来获得当前连接Oracle数据库各个会话占用的CPU时刻，从而得知什么会话耗用服务器CPU比较多。

出现CPU资源不足的情况是专门多的：

SQL语句的重解析、低效率的SQL语句、锁冲突都会引起CPU资源不足。

1、SQL语句的重解析　　

数据库治理员能够执行下述语句来查看SQL语句的解析情况：

SELECT*FROM

V$SYSSTAT

WHERE

NAME

IN（'parsetimecpu',

'parsetimeelapsed','parsecount（hard）'）

那个地点parsetimecpu是系统服务时刻，parsetimeelapsed是响应时刻，用户等待时刻waitetime=parsetimeelapsed-parsetimecpu由此能够得到用户SQL语句平均解析等待时刻=waitetime/parsecount。

那个平均等待时刻应该接近于0，假如平均解析等待时刻过长，数据库治理员能够通过　　

下述语句来发觉是什么SQL语句解析效率比较低：

SELECTSQLJEXT,PARSECALLS,EXECUTIONSFROMV$SQLAREAORDERBYPARSE_CALLS;程序员能够优化这些语句，或者增加Oracle参数SESSION_CACHED_CURSORS的值。

2、低效率的SQL语句　　

数据库治理员还能够通过下述语句来查看低效率的SQL语句：

SELECTBUFFER_GETS,EXECUTIONS,SQL_TEXTFROMV$SQLAREA;优化这些语句也有助于提高CPU的利用率。

3、冲突　　

数据库治理员能够通过v$system_event数据字典中的“latchfree”统计项查看Oracle数据库的冲突情况，假如没有冲突的话，latchfree查询出来没有结果。

假如冲突太大的话，数据库治理员能够降低spin_count参数值，来消除高的CPU使用率。

教你迅速定位路由器故障

当网络出现故障时，如何迅速定位故障点，是评估一个网络治理员能力的一个差不多指标。

笔者今天就以Cisco的路由器路由器为例向大伙儿分享一下如何迅速定位路由器故障，为大伙儿解决网络故障提供一点思路。

尽管Cisco网络设备的稳定性毋庸置疑。

然而，在使用的过程中，仍然会有种种缘故导致网络通信中断。

现在，迅速的找出故障所在，并及时进行修改，是维持系统正常运行的关键。

通常情况下，思科路由器若出现故障的话，只是确实是线路、端口、链路方面出现了某些物理或者配置上的错误。

一、如何推断以太网端口故障?

一般情况下，若因为路由器的缘故导致网络终端，则最可能的缘故确实是以太网的某个端口出现了故障。

事实上，Cisco路由器的ISO软件，本身就提供了许多检测的命令。

通过其自带的命令工具，我们能够特不轻松的发觉一些常规的错误。

如我们能够先推断一下那个以太网端口是否出现了物理上的故障。

现在，我们就能够利用showversion命令。

若使用了那个命令后，发觉你所在用的端口没有显示出来，就表示你用的物理端口出现了故障。

假如你有备用端口的话，只需要换一个既可。

若不幸没有备用端口，那么你可能不得不需要更换一个路由器。

showversion能够显示出所有物理性正常的端口，过滤物理性故障的端口。

若我们排出了以太网端口物理性故障的话，则就需要通过showinterfaceethernet命令，来检测配置上面是否存在一些问题。

假如一切正常的话，则会显示Ethernet0isup，LineProtocoiIsUp。

若路由器没有连接到网络上，即连接故障，则会显示Ethernet0isup，LineProtocoiIsDown。

现在，网络治理员就要考虑是否是连接线出现了问题。

若是接口故障，则路由器会显示Ethernet0isDown，LineProtocoiIsDown提示。

另外，有时候网络故障可能是我们不小心操作所造成的，如错误的把以太网端口关闭了。

现在，路由器会显示Ethernet0isAdministrativelydown。

现在，网络治理员只需要把那个端口重新开启，即能够解决路由器通信故障。

通常情况下，当出现路由器故障时，我们第一个需要检测的确实是以太网端口的工作状态。

现在，我们往往显示推断路由器是否有物理性的故障。

排除那个缘故后，再来看以太网端口与线路连接、配置上的问题。

这要紧是因为排除物理性故障比排除其他故障要容易的多;而且，若是物理性故障的话，你再去检测其他缘故差不多上白搭。

因此，在检测以太网端口故障时，要推断是否是物理性的故障。

二、如何推断串行端口的故障。

假如企业网络与远程通信出现中断的话，则网络治理员就需要推断是否是串行端口出现了故障。

串行端口的检验相对来讲，要比以太网端口的检验负责一些。

通常情况下，要按如下的顺序进行检验。

首先推断线路是否中断。

在路由器上有一些信号指示灯，通过这些灯我们能够推断