SQLServer2000数据库优化方案参考

SQLServer2000数据库优化方案参考
SQLServer2000数据库优化方案参考

1、

6、

7、

SQL Server 2000 数据库优化方案参考

查询速度慢的原因很多,常见如下几种:

没有索引或者没有用到索引(这是查询慢最常见的问题,是程

序设计的缺陷)

2、I/O 吞吐量小,形成了瓶颈效应。

3、没有创建计算列导致查询不优化。

4、内存不足

5、网络速度慢

查询出的数据量过大(可以采用多次查询,其他的方法降低数

量)

锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)

8、sp_lock,sp_who, 活动的用户查看,原因是读写竞争资源。

9、返回了不必要的行和列

10、查询语句不好,没有优化

可以通过如下方法来优化查询

1、把数据、日志、索引放到不同的I/O 设备上,增加读取速度,以前可以将Tempdb应放在RAIDO上,SQL2000不在支持。数据量

(尺寸)越大,提高I/O 越重

要.

2、纵向、横向分割表,减少表的尺寸(sp_spaceuse)

3、升级硬件

4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该

尽量小,使用字节数小的列建索引好(参照索引的创建),不要对有限的

几个值的字段建单一索引如性别字段

5 、提高网速;

6、扩大服务器的内存,Windows 2000 和SQL server 2000 能支持4-8G 的内存。配置虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行配置。运行Microsoft SQL Server? 2000 时,可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5 倍。如果另外安装了全文检索功能,并打算运行Microsoft 搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配置为至少是计算机中安装的物理内存的3 倍。将SQL Server max server memory 服务器

配置选项配置为物理内存的1.5 倍(虚拟内存大小设置的一半)。

7、增加服务器CPU 个数;但是必须明白并行处理串行处理更需

要资源例如内存。使用并行还是串行程是MsSQL 自动评估选择的。

单个任务分解成多个任务,就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY 字句同时执行,SQL SERVER 根

据系统的负载情况决定最优的并行等级,复杂的需要消耗大量的

CPU 的查询最适合并行处理。但是更新操作Update,Insert ,Delete

还不能并行处理。

8、如果是使用like 进行查询的话,简单的使用index 是不行的,但是全文索引,耗空间。like 'a%' 使用索引like '%a' 不使用索引用

like '%a%' 查询时,查询耗时和字段值总长度成正比, 所以不能用

CHAR 类型,而是VARCHAR 。对于字段的值很长的建全文索引。

9、DB Server 和APPLication Server 分离;OLTP 和OLAP 分

10、分布式分区视图可用于实现数据库服务器联合体。联合体是

一组分开管理的服务器,但它们相互协作分担系统的处理负荷。这种

通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器,以支持大型的多层Web 站点的处理需要。有关更多信息,参见

设计联合数据库服务器。(参照SQL 帮助文件'分区视图')

a、在实现分区视图之前,必须先水平分区表

b、在创建成员表后,在每个成员服务器上定义一个分布式分区

视图,并且每个视图具有相同的名称。这样,引用分布式分区视图名的查询可以在任何一个成员服务器上运行。系统操作如同每个成员服务器上都有一个原始表的复本一样,但其实每个服务器上只有一个成

员表和一个分布式分区视图。数据的位置对应用程序是透明的。

11、重建索引DBCC REINDEX ,DBCC INDEXDEFRAG, 收缩

设置自动收

数据和日志DBCC SHRINKDB,DBCC SHRINKFILE.

缩日志.对于大的数据库不要设置数据库自动增长,它会降低服务器

的性能。在T-sql 的写法上有很大的讲究,下面列出常见的要点:首

先,DBMS 处理查询计划的过程是这样的:

1、查询语句的词法、语法检查

2、将语句提交给DBMS 的查询优化器

3、优化器做代数优化和存取路径的优化

4、由预编译模块生成查询规划

5、然后在合适的时间提交给系统处理执行

6、最后将执行结果返回给用户其次,看一下SQL SERVER 的数据存放的结构:一个页面的大小为8K(8060) 字节,8 个页面为一

个盘区,按照B 树存放。

12、Commit 和rollback 的区别Rollback: 回滚所有的事物。Commit: 提交当前的事物. 没有必要在动态SQL 里写事物,如果要写请写在外面如:begin tran exec(@s) commit trans 或者将动态SQL 写成

函数或者存储过程。

13、在查询Select 语句中用Where 字句限制返回的行数,避免表

扫描,如果返回不必要的数据,浪费了服务器的I/O 资源,加重了网络的负担降低性能。如果表很大,在表扫描的期间将表锁住,禁止其他

的联接访问表,后果严重。

14 、SQL 的注释申明对执行没有任何影响

FETCH NEXT 是唯一允许的提取操作,也是默认方式。可滚动性可以

在游标中任何地方随机提取任意行。游标的技术在SQL2000 下变得功能很强大,他的目的是支持循环。有四个并发选项READ_ONLY :不允许通过游标定位更新(Update) ,且在组成结果集的行中没有锁。

OPTIMISTIC WITH valueS: 乐观并发控制是事务控制理论的一个标准部分。乐观并发控制用于这样的情形,即在打开游标及更新行的间隔中,只有很小的机会让第二个用户更新某一行。当某个游标以此选项打开时,没有锁控制其中的行,这将有助于最大化其处理能力。如果用户试图修改某一行,则此行的当前值会与最后一次提取此行时获取的值进行比较。如果任何值发生改变,则服务器就会知道其他人已更新了此行,并会返回一个错误。如果值是一样的,服务器就执行修

改。选择这个并发选项OPT IM ISTIC WITH ROW VERSIONING:

此乐观并发控制选项基于行版本控制。使用行版本控制,其中的表必须具有某种版本标识符,服务器可用它来确定该行在读入游标后是否有所更改。在SQL Server中,这个性能由timestamp数据类型提

供,它是一个二进制数字,表示数据库中更改的相对顺序。每个数据库都有一个全局当前时间戳值:@@DBTS。每次以任何方式更改带

有timestamp列的行时,SQL Server先在时间戳列中存储当前的

@@DBTS值,然后增加@@DBTS的值。如果某个表具有timestamp列,则时间戳会被记到行级。服务器就可以比较某行的当

前时间戳值和上次提取时所存储的时间戳值,从而确定该行是否已更

新。服务器不必比较所有列的值,只需比较timestamp列即可。如

果应用程序对没有timestamp列的表要求基于行版本控制的乐观并

发,则游标默认为基于数值的乐观并发控制。SCROLL LOCKS 这个选项实现悲观并发控制。在悲观并发控制中,在把数据库的行读入

游标结果集时,应用程序将试图锁定数据库行。在使用服务器游标时,将行读入游标时会在其上放置一个更新锁。如果在事务内打开游

标,则该事务更新锁将一直保持到事务被提交或回滚;当提取下一行

时,将除去游标锁。如果在事务外打开游标,则提取下一行时,锁就被丢弃。因此,每当用户需要完全的悲观并发控制时,游标都应在事务内打开。更新锁将阻止任何其它任务获取更新锁或排它锁,从而阻

止其它任务更新该行。然而,更新锁并不阻止共享锁,所以它不会阻

止其它任务读取行,除非第二个任务也在要求带更新锁的读取。滚动

锁根据在游标定义的Select 语句中指定的锁提示,这些游标并发选

项可以生成滚动锁。滚动锁在提取时在每行上获取,并保持到下次提

取或者游标关闭,以先发生者为准。下次提取时,服务器为新提取中

的行获取滚动锁,并释放上次提取中行的滚动锁。滚动锁独立于事务

锁,并可以保持到一个提交或回滚操作之后。如果提交时关闭游标的

选项为关,则COMMIT 语句并不关闭任何打开的游标,而且滚动锁

被保留到提交之后,以维护对所提取数据的隔离。所获取滚动锁的类

型取决于游标并发选项和游标Select 语句中的锁提示。锁提示只

读乐观数值乐观行版本控制锁定无提示未锁定未锁定未锁定

更新NOLOCK 未锁定未锁定未锁定未锁定HOLDLOCK 共享

共享共享更新UPDLOCK 错误更新更新更新TABLOCKX

错误未锁定未锁定更新其它未锁定未锁定未锁定更新* 指定NOLOCK 提示将使指定了该提示的表在游标内是只读的。

16 、用Profiler 来跟踪查询,得到查询所需的时间,找出SQL

的问题所在;用索引优化器优化索引

17、注意UNion 和UNion all 的区别。UNION all

18、注意使用DISTINCT ,在没有必要时不要用,它同UNION

一样会使查询变慢。重复的记录在查询里是没有问题的

19、查询时不要返回不需要的行、列

20 、用sp_configure 'query governor cost

SET limit' 或者

QUERY_GOVERNOR_COST_LIMIT 来限制查询消耗的资源。当评

估查询消耗的资源超出限制时,服务器自动取消查询,在查询之前就

扼杀掉。SET LOCKTIME 设置锁的时间

21 、用select top 100 / 10 Percent 来限制用户返回的行数或者

SET ROWCOUNT 来限制操作的行

22、在SQL2000 以前,一般不要用如下的字句: "IS NULL", "",

"!=", "!>", "!" 等还是不能优化,用不到索引。

23 、使用Query Analyzer ,查看SQL 语句的查询计划和评估分析是否是优化的SQL。一般的20%的代码占据了80%的资源,我们

优化的重点是这些慢的地方。

24 、如果使用了IN 或者OR 等时发现查询没有走索引,使用显

示申明指定索引:Select * FROM PersonMember (INDEX =

IX_Title) Where processid IN (' 男','女')

25、将需要查询的结果预先计算好放在表中,查询的时候再

Select。这在SQL7.0以前是最重要的手段。例如医院的住院费计算。

26、MIN()和MAX()能使用到合适的索引。

27、数据库有一个原则是代码离数据越近越好,所以优先选择

Default, 依次为Rules,Triggers, Constraint( 约束如外健主健

CheckUNIQUE?…,数据类型的最大长度等等都是约束),P rocedure.

这样不仅维护工作小,编写程序质量高,并且执行的速度快。

28、如果要插入大的二进制值到Image 列,使用存储过程,千万不要用内嵌Insert 来插入(不知JAVA 是否)。因为这样应用程序首

先将二进制值转换成字符串(尺寸是它的两倍),服务器受到字符后又

性能优化的方法和技巧

性能优化方法和技巧:概述 性能优化有三个层次: ?系统层次 ?算法层次 ?代码层次 系统层次关注系统的控制流程和数据流程,优化主要考虑如何减少消息传递的个数;如何使系统的负载更加均衡;如何充分利用硬件的性能和设施;如何减少系统额外开销(比如上下文切换等)。 算法层次关注算法的选择(用更高效的算法替换现有算法,而不改变其接口);现有算法的优化(时间和空间的优化);并发和锁的优化(增加任务的并行性,减小锁的开销);数据结构的设计(比如lock-free的数据结构和算法)。 代码层次关注代码优化,主要是cache相关的优化(I-cache, D-cache相关的优化);代码执行顺序的调整;编译优化选项;语言相关的优化技巧等等。 性能优化需要相关的工具支持,这些工具包括编译器的支持;CPU的支持;以及集成到代码里面的测量工具等等。这些工具主要目的是测量代码的执行时间以及相关的cache miss, cache hit等数据,这些工具可以帮助开发者定位和分析问题。 性能优化和性能设计不同。性能设计贯穿于设计,编码,测试的整个环节,是产品生命周期的第一个阶段;而性能优化,通常是在现有系统和代码基础上所做的改进,属于产品生命周期的后续几个阶段(假设产品有多个生命周期)。性能优化不是重新设计,性能优化是以现有的产品和代码为基础的,而不是推倒重来。性能优化的方法和技巧可以指导性能设计,但两者的方法和技巧不能等同。两者关注的对象不同。性能设计是从正向考虑问题:如何设计出高效,高性能的系统;而性能优化是从反向考虑问题:在出现性能问题时,如何定位和优化性能。性能设计考验的是开发者正向建设的能力,而性能优化考验的是开发者反向修复的能力。两者可以互补。

大型ORACLE数据库优化设计方案

大型ORACLE数据库优化设计方案 本文主要从大型数据库ORACLE环境四个不同级别的调整分析入手,分析ORACLE的系统结构和工作机理,从九个不同方面较全面地总结了ORACLE数据库的优化调整方案。 对于ORACLE数据库的数据存取,主要有四个不同的调整级别,第一级调整是操作系统级 包括硬件平台,第二级调整是ORACLE RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化,数据库的整体性能会得到很大的改善。下面从九个不 同方面介绍ORACLE数据库优化设计方案。 一.数据库优化自由结构OFA(Optimal flexible Architecture) 数据库的逻辑配置对数据库性能有很大的影响,为此,ORACLE公司对表空间设计提出了一种优化结构OFA。使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构OFA,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。数据库逻辑设计的结果应当符合下面的准则:(1)把以同样方式使用的段类型存储在一起; (2)按照标准使用来设计系统;(3)存在用于例外的分离区域;(4)最小化表空间冲突;(5)将数 据字典分离。 二、充分利用系统全局区域SGA(SYSTEM GLOBAL AREA) SGA是oracle数据库的心脏。用户的进程对这个内存区发送事务,并且以这里作为高速缓存读取命中的数据,以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA 包括以下几个部分: 1、数据块缓冲区(data block buffer cache)是SGA中的一块高速缓存,占整个数据库大小 的1%-2%,用来存储从数据库重读取的数据块(表、索引、簇等),因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表 说明和权限,它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU算法 管理。如果设置过小,语句将被连续不断地再装入到库缓存,影响系统性能。 另外,SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这

Linux操作系统性能调优的方法

按照传统,Linux不同的发行版本和不同的内核对各项参数及设置均做了改动,从而使得系统能够获得更好的性能。下边将分四部分介绍在Red Hat Enterprise Linux AS和SUSE LINUX Enterprise Server系统下,如何用以下几种技巧进行性能的优化: QUOTE: 1、Disabling daemons (关闭 daemons) 2、Shutting down the GUI (关闭GUI) 3、Changing kernel parameters (改变内核参数) 4、Kernel parameters (内核参数) 5、Tuning the processor subsystem(处理器子系统调优) 6、Tuning the memory subsystem (内存子系统调优) 7、Tuning the file system(文件系统子系统调优) 8、Tuning the network subsystem(网络子系统调优) 1 关闭daemons 有些运行在服务器中的daemons (后台服务),并不是完全必要的。关闭这些daemons可释放更多的内存、减少启动时间并减少CPU处理的进程数。减少daemons数量的同时也增强了服务器的安全性。缺省情况下,多数服务器都可以安全地停掉几个daemons。 Table 10-1列出了Red Hat Enterprise Linux AS下的可调整进程. Table 10-2列出了SUSE LINUX Enterprise Server下的可调整进程.

注意:关闭xfs daemon将导致不能启动X,因此只有在不需要启动GUI图形的时候才可以关闭xfs daemon。使用startx命令前,开启xfs daemon,恢复正常启动X。 可以根据需要停止某个进程,如要停止sendmail 进程,输入如下命令: Red Hat: /sbin/service sendmail stop SUSE LINUX: /etc/init.d/sendmail stop

大数据库优化(SQLServer)

SQL SERVER性能优化综述 近期因工作需要,希望比较全面的总结下SQL SERVER数据库性能优化相关的注意事项,在 网上搜索了一下,发现很多文章,有的都列出了上百条,但是仔细看发现,有很多似是而非或 者过时(可能对SQL SERVER6.5以前的版本或者ORACLE是适用的)的信息,只好自己根据以 前的经验和测试结果进行总结了。 我始终认为,一个系统的性能的提高,不单单是试运行或者维护阶段的性能调优的任务,也不单单是开发阶段的事情,而是在整个软件生命周期都需要注意,进行有效工作才能达到的。所以我希望按照软件生命周期的不同阶段来总结数据库性能优化相关的注意事项。 一、分析阶段 一般来说,在系统分析阶段往往有太多需要关注的地方,系统各种功能性、可用性、可靠性、安全性需求往往吸引了我们大部分的注意力,但是,我们必须注意,性能是很重要的非功能 性需求,必须根据系统的特点确定其实时性需求、响应时间的需求、硬件的配置等。最好能 有各种需求的量化的指标。 另一方面,在分析阶段应该根据各种需求区分出系统的类型,大的方面,区分是OLTP(联机事务处理系统)和OLAP(联机分析处理系统)。 二、设计阶段 设计阶段可以说是以后系统性能的关键阶段,在这个阶段,有一个关系到以后几乎所有性能 调优的过程—数据库设计。 在数据库设计完成后,可以进行初步的索引设计,好的索引设计可以指导编码阶段写出高效 率的代码,为整个系统的性能打下良好的基础。 以下是性能要求设计阶段需要注意的: 1、数据库逻辑设计的规范化 数据库逻辑设计的规范化就是我们一般所说的范式,我们可以这样来简单理解范式: 第1规范:没有重复的组或多值的列,这是数据库设计的最低要求。 第2规范: 每个非关键字段必须依赖于主关键字,不能依赖于一个组合式主关键字的某些组 成部分。消除部分依赖,大部分情况下,数据库设计都应该达到第二范式。 第3规范: 一个非关键字段不能依赖于另一个非关键字段。消除传递依赖,达到第三范式应该是系统中大部分表的要求,除非一些特殊作用的表。 更高的范式要求这里就不再作介绍了,个人认为,如果全部达到第二范式,大部分达到第三

数据库及SQL代码优化方案

1.1、数据库及SQL代码优化方案 (1)每周检查统计信息是否及时更新。 (2)每周检查各索引是否有效。 (3)每周检查分区是否正确。 (4)每周检查执行计划是否正确。 (5)每天检查RAC和ASM是否正常运行。 (6)每天检查相关日志是否正常备份。 (7)每天检查相关文件系统和表空间的占用率是否在国家税务总局规定的阀值以下。 (8)在每月申报高峰等业务繁忙期采样并找出消耗I/O资源和CPU资源较多的SQL语句。 (9)分析上述SQL语句,与软件服务商充分沟通后,提出优化建议。 (10)在每月申报高峰期每隔15分钟检查一次数据库连接数,发现异常及时处理。 1.1.1、系统数据库索引、表分区和对象优化方案 数据库对象的优化主要包括:表、索引和sequence等对象,通过优化对象参数、调整对象属性(例如分区表、分区索引、反转索引等等)等方法来实现对数据库对象的优化改造。 1.1.1.1表和索引并行参数优化 数据库的表和索引的并行参数值的设置对相关的sql语句的执行计划会造成影响,表和索引的degree值大于1,执行计划就偏向于使用全表和全索引扫描,另外如果并行参数值过大,短时间内也会对主机和数据库的资源造成很大的压力,因此在oltp的数据库下建议将表和索引的degree值设为1。 1.1.1.2热点大表的分区改造 对访问量很大、表的记录数很多、存在热块争用的表,可以考虑对表和索引进行适当的分区改造,分散访问压力,提高数据访问的性能。 对以下表的记录数超过1000万并且记录数持续增长的大表,建议进行分区

改造(地区+时间): 1.1.1.3分区索引的清理 对最近30天数据库分区索引访问情况进行统计,对访问次数为0的分区索引和应用部门进行确认,若确认为多余的索引,建议进行删除清理。 1.1.1.4Sequence序列优化 加大sequence 的 cache,并使用noorder选项。在RAC中经常会遇到SQ 锁等待,这是因为在RAC环境下,sequence也成为全局性的了,不同节点要生成序列号,就会产生对sequence资源的争用。而目前大多数系统中,sequence 大多数被作为主键发生器来使用,使用的频率十分高,在RAC环境中,需要设置较大的 sequence cache,否则会造成较为严重的争用,从而影响业务。 1.1.2、SQL硬解析优化方案 1.1. 2.1相关知识点介绍 1.1. 2.1.1Oracle的硬解析和软解析 Oracle对sql的处理过程:当发出一条sql语句交付Oracle,在执行和获取结果前,Oracle对此sql将进行几个步骤的处理过程: 1、语法检查(syntax check) 检查此sql的拼写是否语法。 2、语义检查(semantic check) 诸如检查sql语句中的访问对象是否存在及该用户是否具备相应的权限。 3、对sql语句进行解析(prase) 利用内部算法对sql进行解析,生成解析树(parse tree)及执行计划(execution plan)。 4、执行sql,返回结果(execute and return) 其中,软、硬解析就发生在第三个过程里。 Oracle利用内部的hash算法来取得该sql的hash值,然后在library cache

MS SQL Server 2000数据库安装手册

MS SQL Server 2000数据库安装手册 本系统需要微软SQL Server数据库的支持,因此,运行本系统之前首先段安装微软SQLServer数据库,本手册以SQL Server 2000为例说明安装注意事项。 注:一般情况下本公司不提供Microsoft SQL Server的安装程序,请用户自行购买!1.1 Microsoft SQLServer2000各版本的运行环境 Microsoft SQL Server 2000有企业版、标准版、个人版等版本,与之相匹配的操作系统 操作系统企业版标准版个人版开发版MSDE 评估版Windows 2000 DataCenter 支持支持支持支持支持支持 Windows 2000 Advanced Server 支持支持支持支持支持支持 Windows 2000 Server 支持支持支持支持支持支持 Windows 2000 Professional 支持支持支持支持 Windows 98、WindowsMe 支持支持 1.2 安装Microsoft SQL Server2000 Microsoft SQL Server2000各版本安装步骤基本相同(MSDE 版除外,在1.3说明),下面我们就以微软SQLServer2000个人版为例进行介绍: 将Microsoft SQL Server 2000安装光盘放入光驱后,安装程序将自动运行;也可手动双击执行光盘根目录下的autorun.exe。安装界面中共有5个选项,单击【安装SQL Server 2000组件(C)】选项,如下图; 在接着出现的安装界面中选择【安装数据库服务器(S)】选项;

系统性能优化方案

系统性能优化方案 (第一章) 系统在用户使用一段时间后(1年以上),均存在系统性能(操作、查询、分析)逐渐下降趋势,有些用户的系统性能下降的速度非常快。同时随着目前我们对数据库分库技术的不断探讨,在实际用户的生产环境,现有系统在性能上的不断下降已经非常严重的影响了实际的用户使用,对我公司在行业用户内也带来了不利的影响。 通过对现有系统的跟踪分析与调整,我们对现有系统的性能主要总结了以下几个瓶颈: 1、数据库连接方式问题 古典C/S连接方式对数据库连接资源的争夺对DBServer带来了极大的压力。现代B/S连接方式虽然不同程度上缓解了连接资源的压力,但是由于没有进行数据库连接池的管理,在某种程度上,随着应用服务器的不断扩大和用户数量增加,连接的数量也会不断上升而无截止。 此问题在所有系统中存在。 2、系统应用方式(架构)问题(应用程序设计的优化) 在业务系统中,随着业务流程的不断增加,业务控制不断深入,分析统计、决策支持的需求不断提高,我们现有的业务流程处理没有针对现有的应用特点进行合理的应用结构设计,例如在‘订单、提油单’、‘单据、日报、帐务的处理’关系上,单纯的数据关系已经难以承载多元的业务应用需求。 3、数据库设计问题(指定类型SQL语句的优化)

目前在系统开发过程中,数据库设计由开发人员承担,由于缺乏专业的数据库设计角色、单个功能在整个系统中的定位模糊等原因,未对系统的数据库进行整体的分析与性能设计,仅仅实现了简单的数据存储与展示,随着用户数据量的不断增加,系统性能逐渐下降。 4、数据库管理与研究问题(数据存储、物理存储和逻辑存储的优化) 随着系统的不断增大,数据库管理员(DBA)的角色未建立,整个系统的数据库开发存在非常大的随意性,而且在数据库自身技术的研究、硬件配置的研究等方面未开展,导致系统硬件、系统软件两方面在数据库管理维护、研究上无充分认可、成熟的技术支持。 5、网络通信因素的问题 随着VPN应用技术的不断推广,在远程数据库应用技术上,我们在实际设计、开发上未充分的考虑网络因素,在数据传输量上的不断加大,传统的开发技术和设计方法已经无法承载新的业务应用需求。 针对以上问题,我们进行了以下几个方面的尝试: 1、修改应用技术模式 2、建立历史数据库 3、利用数据库索引技术 4、利用数据库分区技术 通过尝试效果明显,仅供参考!

数据库性能优化基础步骤

1性能优化基本步骤 1.1定位跟踪耗费资源较多的SQL语句步骤 1.1.1 通过SQL查询 (1): 查询出最耗费资源的SQL语句 select t1.SID, t1.SERIAL#, tt.HASH_VALUE, tt.ADDRESS, tt.BUFFER_GETS, --读内存次数 tt.DISK_READS, --磁盘物理读次数 tt.EXECUTIONS, --语句的执行次数 tt.BUFFER_GETS / tt.EXECUTIONS, --平均读内存次数 tt.SQL_FULLTEXT from v$sqlareatt, v$session t1 where (tt.BUFFER_GETS>100000 or tt.DISK_READS>100000) and tt.HASH_VALUE = t1.SQL_HASH_VALUE and tt.ADDRESS = t1.SQL_ADDRESS and t1.STATUS = 'ACTIVE' orderby tt.BUFFER_GETS desc (2):根据客户端程序发出的SQL来定位需要跟踪的session select s.sid sid, s.SERIAL# "serial#", https://www.360docs.net/doc/f83408596.html,ername, s.machine, s.program, s.server, s.LOGON_TIME from v$session s 1.1.2 通过Oracle提供的SQL TRACE进行SQL跟踪 (1):跟踪前设定相应参数 1.查询得到需要跟踪的session 2.打开时间开关

Show parameter timed_statistics alter session set timed_statistics=true; execsys.dbms_system.set_bool_param_in_session(sid => 8,serial# => 3,parnam => 'timed_statistics',bval => true); 3.设置跟踪文件存放位置 Show parameter user_dump_dest alter system set user_dump_dest='c:\temp'; (2):启动跟踪功能并让系统运行一段时间 alter session set sql_trace=true; execsys.dbms_system.set_sql_trace_in_session(8, 3, true); (3):关闭跟踪功能 alter session set sql_trace=false; execsys.dbms_system.set_sql_trace_in_session(8, 3, false); (4):格式化跟踪数据文件,并分析跟踪结果文件 tkprof dsdb2_ora_18468.trc dsdb2_trace.txt EXPLAIN=SCOTT/TIGER tkprof各参数含义: ' traced_file ' 指定输入文件,即oracle产生的trace文件 'formatted_file'指定输出文件,即我们想得到的易于理解的格式化文件 'EXPLAIN' 利用哪个用户对trace文件中的sql进行分析得到该sql语句的执行计划1.2查看分析执行计划 1.2.1查看执行计划 (1):Sqlplus中可按F5查看执行计划 (2):使用执行计划表进行查看 使用语句将SQL语句的执行计划装入plan_table表,然后进行分析查看explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value (3):示例演示 1.让ORALCE自动选择最优的执行计划,不人为干预 explainplansetstatement_id = 'dd'into plan_table for select t.type_name,t.source_value,t.standard_value from ODS_STD_COMP t,ODS_STD_COMP_BAK t1 where t.system_id = t1.system_id and t.type = t1.type and t.source_value = t1.source_value

大型数据库的优化方法及实例

大型数据库的优化方法及实例 尹德明杨富玉杨莹时鹏泉 中国金融电子化公司 E_mail: dm_mis@https://www.360docs.net/doc/f83408596.html, 1.引言 随着银行业数据集中,作为整个系统核心的数据库,其存放、管理的数据越来越庞大,已经超越GB而到达TB数据量层次,数据库的性能成为整个系统性能的关键。 国库会计核算系统是国库部门用以进行国库业务的会计核算,并通过支付系统、国库内部往来、同城票据交换系统进行资金清算的计算机网络系统。国家金库会计核算系统每天处理的税票数据多达10万笔,税收高峰可能会到100万笔,这样一年累计下来其中历史登记簿中的数据达到2000万条以上,给检索和数据处理带来非常大的困难。 如何对于一个已经上线运行的重要业务系统,通过对数据库的优化和简单的系统流程调整,实现系统性能的大幅提升具有现实、迫切、重要的意义。 2.优化策略 根据Sybase的数据存储机制,在进行一段时期的数据删除、插入和更新等操作后,数据库往往会产生大量的碎片。大量碎片的存在,会严重影响数据库的I/O性能,如果在使用数据库一段时间后,整理碎片,可以提高数据库的性能。由于国家金库会计核算系统在预处理、日间报解、日初始化等步骤,会大批量进行数据删除、插入和更新等操作,因此会产生大量的数据碎片。碎片整理对于国家金库会计核算系统性能优化将会有重要效果。 Sybase Adaptive Server对于按顺序存储和访问的页,在单个I/O中最多读取八个数据页。由于大部分I/O时间都花在磁盘上的物理定位和搜寻上,因此大I/O可极大地减少磁盘访问时间。在大多数情况下,希望在缺省数据高速缓存中配置一个16K缓冲池。为事务日志创建4K缓冲池可极大地减少数据库系统日志写操作的数量。 好的性能同优良的数据库设计及优秀的程序写法关系极大,可以这样说,如果一个数据库没有好的设计及对程序未进行优化的话即使对参数进行调整也不可能有好的性能。 3.数据库碎片整理 由于Sybase是通过OAM页、分配单元和扩展页来管理数据的,所以对OLTP应用的Database Server会十分频繁地进行数据删除、插入和更新等操作,时间一长就会出现以下几种情况: (1)页碎片 即本来可以存放在一个页上的数据却分散地存储在多个页上。如果这些页存储在不同的扩展单元上,Database Server就要访问多个扩展单元,因此降低了系统性能。 (2)扩展单元碎片 在堆表中,当删除数据链中间的记录行时,会出现空页。随着空页的累积,扩展单元的利用率也会下降,从而出现扩展单元碎片。带cluster index的table也有可能出现扩展单元碎片。当有扩展单元碎片存在,会出现以下问题: 对表进行处理时,常常出现死锁;利用较大的I/O操作或增加I/O缓冲区的大小也无法改变较慢的I/O速度;行操作的争用。 (3)扩展单元遍历 带有cluster index的table会由于插入记录而导致页分裂,但当删除记录后,页会获得释放,从而形成跨几个扩展单元和分配单元的数据,而要访问该数据就必须遍历几个扩展单元和分配单元。这将导致访问/查询记录的时间大大延长,开始时数据库的性能虽然较高,

SQL SERVER2000数据备份与恢复

SQL Server2000数据备份与恢复 Author looger 1.数据库备份 1.1展开服务器组,然后展开服务器。展开“数据库”文件夹,右击数据库,指向“所 有所有”子菜单,然后单击“备份数据库”命令。 1.2在“名称”框内输入备份集名称,在“描述”框中输入对备份集的描述。在“备 份”选项中选择备份方式。

1.3点击“添加”按钮以添加现有的目的地或创建新的目的地,点击按钮可以选择一个备份文件

1.4点击按钮后,在下面出现的窗口中选择一个文件作为备份文件,可以在“文件名” 后面的文本框中输入一个新的文件名以创建一个备份文件。 1.5此时刚才选择的文件被加入到备份文件中。如果要添加其他的文件,则可以点击“添 加”按钮添加其他的文件。在"重写"选项下,单击“追加到媒体”,将备份追加到备份设备上任何现有的备份中;点击“重写现有媒体”,将重写备份设备中任何现有的备份

1.6可以选择“调度”复选框调度备份操作在以后执行或定期执行。点击“调度”后 面的按钮可以对调度进行设置 1.7在点击按钮后,可以在下面的对话框中设置调度的名称和调度的类型。如果需要调 度反复出现,则可以点击“更改”按钮

1.8点击“更改”按钮后,可以在下面的窗口中设置作业发生的时机 1.9单击“选项”选项卡。选择“完成后验证备份”复选框,在备份时对备份进行验 证。选择“检查媒体集名称和备份集到期时间”,检查备份媒体以防意外重写。在“媒体集名称”框中,输入将用于备份操作的媒体的名称。如果仅指备份集到期时间,则将其保留为空

2.数据库的恢复 2.1展开服务组,然后展开服务器。展开“数据库”文件夹,右击数据库, 指向“所有任务”子菜单,然后单击“还原数据库”命令 2.2在“还原为数据库”框中,如果要还原的数据库名称与显示的默认数据库名称不同,请在其中进行输入或选择。若要用新名称还原数据库,请输入新的数据库名称

安卓性能优化方案

随着技术的发展,智能手机硬件配置越来越高,可是它和现在的PC相比,其运算能力,续航能力,存储空间等都还是受到很大的限制,同时用户对手机的体验要求远远高于PC的桌面应用程序。以上理由,足以需要开发人员更加专心去实现和优化你的代码了。选择合适的算法和数据结构永远是开发人员最先应该考虑的事情。同时,我们应该时刻牢记,写出高效代码的两条基本的原则:(1)不要做不必要的事;(2)不要分配不必要的内存。 我从去年开始接触Android开发,以下结合自己的一点项目经验,同时参考了Google的优化文档和网上的诸多技术大牛给出的意见,整理出这份文档。 1. 内存优化 Android系统对每个软件所能使用的RAM空间进行了限制(如:Nexus o ne 对每个软件的内存限制是24M),同时Java语言本身比较消耗内存,d alvik虚拟机也要占用一定的内存空间,所以合理使用内存,彰显出一个程序员的素质和技能。 1) 了解JIT 即时编译(Just-in-time Compilation,JIT),又称动态转译(Dynamic Translation),是一种通过在运行时将字节码翻译为机器码,从而改善字节码编译语言性能的技术。即时编译前期的两个运行时理论是字节码编译和动态编译。Android原来Dalvik虚拟机是作为一种解释器实现,新版

(Android2.2+)将换成JIT编译器实现。性能测试显示,在多项测试中新版本比旧版本提升了大约6倍。 详细请参考https://www.360docs.net/doc/f83408596.html,/cool_parkour/blog/item/2802b01586e22cd8a6ef3f6b. html 2) 避免创建不必要的对象 就像世界上没有免费的午餐,世界上也没有免费的对象。虽然gc为每个线程都建立了临时对象池,可以使创建对象的代价变得小一些,但是分配内存永远都比不分配内存的代价大。如果你在用户界面循环中分配对象内存,就会引发周期性的垃圾回收,用户就会觉得界面像打嗝一样一顿一顿的。所以,除非必要,应尽量避免尽力对象的实例。下面的例子将帮助你理解这条原则: 当你从用户输入的数据中截取一段字符串时,尽量使用substring函数取得原始数据的一个子串,而不是为子串另外建立一份拷贝。这样你就有一个新的String对象,它与原始数据共享一个char数组。如果你有一个函数返回一个String对象,而你确切的知道这个字符串会被附加到一个Stri ngBuffer,那么,请改变这个函数的参数和实现方式,直接把结果附加到StringBuffer中,而不要再建立一个短命的临时对象。 一个更极端的例子是,把多维数组分成多个一维数组: int数组比Integer数组好,这也概括了一个基本事实,两个平行的int数组比(int,int)对象数组性能要好很多。同理,这试用于所有基本类型的组合。如果你想用一种容器存储(Foo,Bar)元组,尝试使用两个单独的Foo[]

SQL Server数据库优化方案汇总

SQL Server数据库优化方案汇总 50种方法优化SQL Server 1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷) 2、I/O吞吐量小,形成了瓶颈效应。 3、没有创建计算列导致查询不优化。 4、内存不足 5、网络速度慢 6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量) 7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷) 8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。 9、返回了不必要的行和列 10、查询语句不好,没有优化 可以通过如下方法来优化查询 : 1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。数据量(尺寸)越大,提高I/O越重要. 2、纵向、横向分割表,减少表的尺寸(sp_spaceuse) 3、升级硬件 4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。注意填充因子要适当(最好是使用默认值0)。索引应该尽量小,使 用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段 5、提高网速; 6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。配置虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行 配置。运行 Microsoft SQL Server? 2000 时,可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。如果另外安装了全文检索功能,并打算 运行 Microsoft 搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。将 SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍(虚拟内存大小设置的一半)。 7、增加服务器 CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MsSQL自动评估选择的。单个任务分解成 多个任务,就可以在处理器上运行。例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行,SQL SERVER根据系统的负载情况决定最优的并 行等级,复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作Update,Insert, Delete还不能并行处理。 8、如果是使用like进行查询的话,简单的使用index是不行的,但是全文索引,耗空间。 like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查询时,查询耗时和字段值总长度成正比,所以不能用CHAR类型,而是VARCHAR。对于字段的值很长的建全文索引。 9、DB Server 和APPLication Server 分离;OLTP和OLAP分离

系统性能调优方案

第1章系统性能调优方案 1.1系统的性能扩展模型介绍 在进行性能指标设计工作前,必须从理论上对性能指标的可实现性进行分析。理论上,系统的扩展模型可以分成两类,系统可扩展模型和不可扩展模型,如下图所示: 两种性能扩展模型 以上左图代表了系统随着并发用户量的增加系统响应时间呈现线性增长的 趋势,是一种可扩展的情况;但对于系统右边的方式则是不可扩展的,它将随着用户数量的增大而响应时间大大急剧增加,这种模型是完全不可控制的。 通过系统压力实验,我们发现,即使是遵循可扩展模型设计的系统的响应性能和并发用户量并不能成永远的线性关系,在系统压力超过一定的值之后,如100并发,系统响应时间增加非常快,我们把这个点称为拐点。在拐点以下,系统性能呈现良好的线性特性,在拐点以上,则呈现出非线性的特征,同时CPU 和内存出现相当大的增长,甚至100%占用。这种现象的出现,说明系统的性能 不仅仅取决于软件系统,而也同时取决于承载系统的硬件基础环境,如计算能力和内存大小。 为此,系统性能设计的目的就是为系统设置合理的拐点并发值,而不可能无限制的追求无限大的并发下系统响应仍旧呈现线形特征。

1.2对响应时间的技术保障手段 金税三期工程第二阶段河南地税建设项目财务管理子系统对系统的性能要求是比较高的,为了满足这个要求,在系统实现上必须要采用一系列的技术措施才能达到,具体来说将采用下面方式进行: 1、预处理技术的应用 预处理技术是一种在预定计划上由系统激发主动执行的计算模式,它对于一些处理内容固定,处理方式固定的功能非常有效,通过提前处理,实现数据生成时间和数据访问时间的隔离,在数据访问的时候不再需要为拿到结果而执行任何的计算,只需要简单的查询结果即可,这样可以大大增强系统的访问性能,有效的利用系统闲置时间。 2、变动态内容查找为静态数据访问 一些情况下,经过各种调优手段仍不能满足要求,就需要将一些动态的内容进行静态化处理,如可以将复杂的动态报表转化成HTML网页并发布在WEB服务器上,这种方式可以大大减轻应用服务器的访问压力,进一步减少用户等待的时间。例如,对一段历史时期的数据的汇总报表结果的查询,复杂报表结果等查询。 3、异步功能调用模式 对一些耗时较长的处理内容,如果必须由人工进行启动,那么,可以采用这种方式,用户调用程序的时候,实际上只是发送了一个消息给后台服务器,并在服务器端注册信息处理完后需要回馈的客户端,然后系统提示用户系统正在或很快处理这个任务,这样,立刻就能够解放用户,用户可以利用在后台处理的时间去处理其他的任务,在系统处理完后,采用推技术(push),将处理结果提示给用户,从而完成功能的调用全过程。 4、浏览器显示时采用分页、分时显示技术 用户从数据库查询得到的数据如果行数比较多,比如大于100行。在IE端显示就需要花费很长时间,有时让查询人员无法忍受。分页技术,就是利用先显示结果的一部分,一般结果的前50条记录,后面的记录通过翻页的功能去显示其余部分。比如在查询正常计划详细列表页面时,通过查询得到1000条记录,

数据库优化设计方案

数据库优化方案设计 XX信息管理平台从大型数据库环境四个不同级别的调整分析入手,分析数据库平台的系统结构和工作机理,从九个不同方面设计数据库的优化方案。 对于数据库的数据优化,主要有四个不同的调整级别,第一级调整是操作系统级包括硬件平台,第二级调整是RDBMS级的调整,第三级是数据库设计级的调整,最后一个调整级是SQL级。通常依此四级调整级别对数据库进行调整、优化,数据库的整体性能会得到很大的改善。下面从九个不同方面介绍数据库优化设计方案。 一、数据库优化自由结构 数据库的逻辑配置对数据库性能有很大的影响。为此,数据库平台一般对表空间设计提出有相应的优化结构,如ORACLE公司的OFA(Optimal flexible Architecture),使用这种结构进行设计会大大简化物理设计中的数据管理。优化自由结构,简单地讲就是在数据库中可以高效自由地分布逻辑数据对象,因此首先要对数据库中的逻辑对象根据他们的使用方式和物理结构对数据库的影响来进行分类,这种分类包括将系统数据和用户数据分开、一般数据和索引数据分开、低活动表和高活动表分开等等。 数据库逻辑设计的结果应当符合下面的准则: (1)把以同样方式使用的段类型存储在一起; (2)按照标准使用来设计系统; (3)存在用于例外的分离区域; (4)最小化表空间冲突; (5)将数据字典分离。 二、充分利用系统全局区域 系统全局区域是数据库平台的心脏,如Oracle数据库的SGA(SYSTEM GLOBAL AREA) 。用户的进程对这个内存区发送事务,并且以这里作为高速缓存读取命中的数据,以实现加速的目的。正确的SGA大小对数据库的性能至关重要。SGA包括以下几个部分: 1、数据块缓冲区(data block buffer cache)是SGA中的一块高速缓存,占整个数据库大小的1%-2%,用来存储从数据库重读取的数据块(表、索引、簇等),因此采用least recently used (LRU,最近最少使用)的方法进行空间管理。 2、字典缓冲区。该缓冲区内的信息包括用户账号数据、数据文件名、段名、盘区位置、表说明和权限,它也采用LRU方式管理。 3、重做日志缓冲区。该缓冲区保存为数据库恢复过程中用于前滚操作。 4、SQL共享池。保存执行计划和运行数据库的SQL语句的语法分析树。也采用LRU 算法管理。如果设置过小,语句将被连续不断地再装入到库缓存,影响系统性能。 另外,SGA还包括大池、JAVA池、多缓冲池。但是主要是由上面4种缓冲区构成。对这些内存缓冲区的合理设置,可以大大加快数据查询速度,一个足够大的内存区可以把绝大多数数据存储在内存中,只有那些不怎么频繁使用的数据,才从磁盘读取,这样就可以大大提高内存区的命中率。 三、规范与反规范设计数据库

SQL数据库优化方法

SQL数据库优化方法

目录 1 系统优化介绍 (1) 2 外围优化 (1) 3 SQL优化 (2) 3.1 注释使用 (2) 3.2 对于事务的使用 (2) 3.3 对于与数据库的交互 (2) 3.4 对于SELECT *这样的语句, (2) 3.5 尽量避免使用游标 (2) 3.6 尽量使用count(1) (3) 3.7 IN和EXISTS (3) 3.8 注意表之间连接的数据类型 (3) 3.9 尽量少用视图 (3) 3.10 没有必要时不要用DISTINCT和ORDER BY (3) 3.11 避免相关子查询 (3) 3.12 代码离数据越近越好 (3) 3.13 插入大的二进制值到Image列 (4) 3.14 Between在某些时候比IN 速度更快 (4) 3.15 对Where条件字段修饰字段移到右边 (4) 3.16 在海量查询时尽量少用格式转换。 (4) 3.17 IS NULL 与IS NOT NULL (4) 3.18 建立临时表, (4) 3.19 Where中索引的使用 (5) 3.20 外键关联的列应该建立索引 (5) 3.21 注意UNion和`UNion all 的区别 (5) 3.22 Insert (5) 3.23 order by语句 (5) 3.24 技巧用例 (6) 3.24.1 Sql语句执行时间测试 (6)

1系统优化介绍 在我们的项目中,由于客户的使用时间较长或客户的数据量大,造成系统运行速度慢,系统性能下降就容易造成数据库阻塞。这是个非常痛苦的事情,用户的查询、新增、修改等需要花很多时间,甚至造成系统死机的现象。速度慢的原因主要是来自于资源不足。 数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。最常见的优化手段就是对硬件的升级。根据统计,对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升,全部加起来最多只占数据库系统性能提升的40%左右(我将此暂时称之为外围优化);其余大部分系统性能提升来自对应用程序的优化,对于应用程序的优化可以分为对源代码的优化及数据库SQL语句的优化。在本文档只介绍外围优化及SQL语句的优化,对于源代码的优化需要相关方面的专家,形成统一的规范。 一个数据库系统的生命周期可以分成:设计、开发和成品三个阶段。在设计阶段进行数据库性能优化的成本最低,收益最大。在成品阶段进行数据库性能优化的成本最高,收益最小。规范的代码和高性能的语句,功在平时,利在千秋。 2外围优化 1、将操作系统与SQL数据库的补丁打到最高版本,WIN2003最高补丁是SP4, SQL SERVER2000最高补丁是SP4(版本号:2039)。 2、在服务器上不要安装与VA程序任何无相关的软件,甚至一些与VA运行 无关的服务都可以停掉。一般只安装SQL数据库、VA服务端服务及杀毒 软件。 3、杀毒软件避免对大文件进行扫描,特别是数据库(MDF和LDF)文件,一 定要从杀毒软件的范围内排除掉。 4、在进行服务器分区时,分区不要太多,两三个分区就可以了。分区最好 都使用NTFS格式。

22提供性能优化方案---Google-Code

Linux系统性能测试与分析 1、前言 通过对系统中和性能相关的各个环节的介绍,使大家知道出现性能问题时可以从那些方面入手去查,而分析典型应用对系统资源使用的特点,让大家对应用和系统资源的依赖有了更直观的认识。大多数的硬件性能问题主要和CPU、磁盘、内存相关,还没有遇到因为开发语言的运行效率对整个应用的性能造成影响,而应用程序设计的缺陷和数据库查询的滥用反倒是最最常见的性能问题。需要注意的是,大多数情况下,虽然性能瓶颈的起因是程序性能差或者是内存不足或者是磁盘瓶颈等各种原因,但最终表现出的结果就是CPU耗尽,系统负载极高,响应迟缓,甚至暂时失去响应,因此我们观察服务器状况时,最先看的就是系统负载和CPU空闲度。当你阅读完了这遍文档以后就会有一个对系统分析的思路。 2、性能分析的目的 2.1找出系统性能瓶颈 1.硬件瓶颈 2.软件瓶颈 2.2提供性能优化方案 1.升级硬件 2.改进系统结构 达到合理的硬件和软件配置,使系统资源使用达到平衡。但遗憾的是解决一个性能瓶颈,往往又会出现另外的瓶颈或者其他问题,所以性能优化更加切实的目标是做到在一定范围内使系统的各项资源使用趋向合理和保持一定的平衡。系统运行良好的时候恰恰也是各项资源达到了一个平衡体,任何一项资源的过渡使用都会造成平衡体系破坏,从而造成系统负载极高或者响应迟缓。比如CPU过渡使用会造成大量进程等待 CPU资源,系统响应变慢,等待会造成进程数增加,进程增加又会造成内存使用增加,内存耗尽又会造成虚拟内存使用,使用虚拟内存又会造成磁盘IO增加和CPU开销增加(用于进程切换、缺页处理的CPU开销) 3、性能相关的各个环节 3.1 硬件资源 3.1.1、CPU ⒈ 是否使用SMP。 ⒉ 单颗CPU的性能对依赖CPU的某些应用的影响很严重,比如数据库的查询处理。 3.1.2、内存

MS_SQL_Server_数据库性能优化方法总结

1.列出数据库服务器、Web服务器的基本的硬件配置,如CPU、内存等。 2.检查数据库服务器是否真正启用了AWE内存。 (1) 启用AWE:数据库服务器检查C:\boot.ini文件,需要配置"/PAE"(*重启电脑才能生效),如下: [boot loader] timeout=30 default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS [operating systems] multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Windows Server 2003, Enterprise" /noexecute=optout /fastdetect /PAE (2) 开启sql server 服务用户的,内存中锁定页面权限 (*重启电脑才能生效)在“服务管理”中查看 SQL SERVER 服务登录账户,默认是本地系统帐户(System)。然后在运行 gpedit.msc ,选择计算机配置->windows 设置->安全设置->本地策略->用户权限分配->内存中锁定页面。添加SQL SERVER服务的登录用户到里面去。 (3)启用数据库AWE内存,以服务器8G内存为例,一般设置如下,最小2G,最大6G(重启SQL SERVER服务即可): (4)跟踪数据库性能“Total Server Memory ”的使用情况,看看数据库真正使 用的内存,越接近为数据库分配的最大内存越好。 或使用如下语句,查询数据库的内存使用情况: use master go select * from sysperfinfo where counter_name like '%Total Server Memory(KB)%' go 3.Web服务器监控项:

相关文档
最新文档