S y b a s e数据库性能调
优
Sybase数据库性能调优
1．5
用sp_sysmon可以得到数据库系统的性能基准报告，但要在比较稳定的状态下产生，方可作为参考和对照的依据。
1．6 理解存储方法
只有清楚数据库存储数据的底层细节，如数据页、索引页的物理结构，每一行的大小计算，不同类型列占用的宽度等等问题，才能对各种调优措施有个深入领会。关于这个问题，比较复杂和细致，请自行参阅有关书籍。
一般地，对于更改数据的操作，要尽量促进数据库进行直接更新（ Direct Updates ），所以要遵守以下几条原则：
1）除非必要，避免使用允许null值的列和可变长度的列。
2）如果varchar 和varbinary 列填充得比较满，毫不犹豫转成 char 和binary 列。
对于建表时指定的页填充率（page fillfactor）参数，要权衡确定数值大小。一般：小值，适合于有许多随机插入的表，该表的数据经常被删除，又经常被增
加；大值，适合于大多数的数据被增加到表末尾，如客票系统的售票存根和退票存根表。
2 SQL Server级的调优
2．1 管理共享内存
数据库性能优化的首要方面是最优管理内存。数据库占用的共享内存分成数据缓冲（data cache）、存储过程缓冲（Procedure cache）等几块。在isql 下使用 sp_configure 'cache' 可以看到存储过程缓冲所占百分比（procedure cache percent），整个数据缓冲大小（total datacache size）等参数。
2．1．1 存储过程缓冲（Procedure cache）
存储过程缓冲保持以下对象的查询计划：
Procedures ：存储过程
Triggers ：触发器
Views ：视图
Rules ：规则
Defaults ：缺省
Cursors ：游标
存储过程不可重入，意即每个并发用户调用都会在内存中产生一个拷贝。Procedure, triggers, and views 当它们被装载到procedure cache中时，被查询优化器优化，建立查询计划。如果存储过程在缓冲中，被调用时就不需要重新编译。如果procedure cache太小，存储过程就会经常被其他调入内存的存储过程冲洗掉，当再次被调用时，存储过程又被调入内存，再重新编译，用户
请求因此不得不等待。最严重的情况，如果procedure cache不够，存储过程甚至都不能运行。所以在内存足够的情况下，procedurecache percent 参数尽可能大一些。
2．1．2 数据缓冲（Data Cache）
数据缓冲用来缓存数据页和索引页，是除去存储过程缓冲，系统其他占用的缓冲外的剩余内存空间。通过给服务器增加物理内存扩大数据缓冲，是最有效的方法。当然，如果不能加内存，就只能通过减少存储过程缓冲的比例等方法来扩大数据缓冲了。
通过 sp_configure "extent I/O buffers", 20（可调）命令，在Data Cache中保留一些页专用于创建索引时使用，可以显著提高创建索引的性能。但要注意每开辟一个缓冲占用16K 字节的系统内存。
2．1．3 命名缓冲
通过如下的命令：
1> sp_helpcache
2> go
查看某客票数据库中命名缓冲，得到的结果如下：
Cache Name Config Size Run Size Overhead
------------------------------------- ---------- ----------
DS30_Tran_Log 20.00 Mb 20.00 Mb 2.05 Mb
Systemtable 20.00 Mb 20.00 Mb 2.05 Mb
default datacache 0.00 Mb 4462.86 Mb 464.97 Mb
left_base_center 16.00 Mb 16.00 Mb 1.57 Mb
price_cache 8.00 Mb 8.00 Mb 0.85 Mb
可以看出有4个命名缓冲，分别绑定客票系统的应用日志表、一些重要且常用的系统表、余票表、票价系列表，另外1个是缺省数据缓冲。这种配置还不是最合理，应该进一步把Systemtable这个命名缓冲细分成很多个，每一个单独存放一张系统表。
2．1．4 缓冲策略
缓冲策略是指把数据提前读入内存的机制，分预取策略(Prefetch Strategy，即大I/O策略)和取后马上丢弃策略(Fetch-and-Discard)、提示策略(Hints)等几种。
可以在三个级别上设置表数据的预取策略(Prefetch Strategy，即大I/O策略)于：对象级，会话级，查询级。如果三个级别上都有设置，它们发生作用的优先顺序是：对象级> 会话级 > 查询级。
对于如何在查询级利用指定的缓冲池，可以查看下面例子（使用4K缓冲池）：
select au_fname,au_lname
from authers(prefetch 4)
where au_id in (A372020631, ..., A1887081515 )
go
DSS应用往往得益于大的I/O，应该放开large I/O strategy预取策略。
如果一个应用倾向于OLTP特征，用户能在会话级关掉Prefetch来提高性能。对于OLTP应用，关闭large I/O strategy预取策略。
对于所取到的页不会有重用的情况，放开fetch-and-discard策略。客票系统对存根数据进行统计的应用，如财收日结账，营销分析数据整理模块和综合查询等，都可以利用这一结论。
（Oracle管理）Oracle SQL性能优化方法
OracleSQL性能优化方法探讨 Oracle性能优化方法(SQL篇)1 1综述2 2表分区的应用2 3访问Table的方式3 4共享SQL语句3 5选择最有效率的表名顺序5 6WHERE子句中的连接顺序．6 7SELECT子句中避免使用’*’6 8减少访问数据库的次数6 9使用DECODE函数来减少处理时间7 10整合简单,无关联的数据库访问8 11删除重复记录8 12用TRUNCATE替代DELETE9 13尽量多使用COMMIT9 14计算记录条数9 15用Where子句替换HAVING子句9 16减少对表的查询10 17通过内部函数提高SQL效率.11 18使用表的别名(Alias)12 19用EXISTS替代IN12 20用NOT EXISTS替代NOT IN13 21识别低效执行的SQL语句13
22使用TKPROF 工具来查询SQL性能状态14 23用EXPLAIN PLAN 分析SQL语句14 24实时批量的处理16
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要经过反反复复的过程。在数据库建立时，就能根据应用的需要合理设计分配表空间以及存储参数、内存使用初始化参数，对以后的数据库性能有很大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积累经验，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来说明对数据库性能如何进行优化。 2表分区的应用 对于海量数据的表，可以考虑建立分区以提高操作效率。建立分区一般以关键字为分区的标志，也可以以其他字段作为分区的标志，但效率不如关键字高。建立分区的语句在建表时可以进行说明： createtableTABLENAME(
1系统问题 XX公司BI系统上线运行以来，客户反映系统目前存在着下面的几个问题，涉及到数据库和ETL. 问题一：表空间增长太快，每个月需增加3—5G空间。 问题二：ETL JOB会经常导致数据库产生表空间不足错误。 2系统优化分析 2.1分析思路 要解决表空间的问题，我们必须搞清楚下面几个问题： 思路一：真正每个月数据仓库增量是多少空间 目的：得出一个正确的月表空间增长量。 思路二：目前的数据仓库表空间是是如何分布的。 目的：找出那些对象是最占空间，分析其合理性。 2.2分析过程 要得到真实的数据分布必须对表进行分析，首先需要对数据仓库的oracle数据库进行表分析，。执行下面脚本可以对数据库进行表分析。
脚本一 analyze table SA_IMS_PRODUCT_GROUP compute statistics; analyze table SA_CONSUMP_ACT_DEL compute statistics; analyze table SA_FINANCE_ACT compute statistics; analyze table SA_CONSUMP_TGT_DEL compute statistics; analyze table SA_FACT_IS compute statistics; analyze table SA_CPA compute statistics; analyze table SA_REF_TERR_ALIGNMENT_DEL compute statistics; analyze table SA_IMS_MTHLC_BK compute statistics; analyze table SA_IMS_CHPA compute statistics; analyze table SA_FINANCE_PNL compute statistics; analyze table SA_CUST_TARG_SEG compute statistics; analyze table SA_CONSUMP_ACT compute statistics; analyze table SA_FINANCE_BS compute statistics; analyze table SA_FINANCE_BGT_QTY compute statistics; analyze table SA_CONSUMP_ACT0423 compute statistics; analyze table SA_CALLS compute statistics; analyze table SA_COMPANY_DAILY_SALES_ALL compute statistics; analyze table SA_IMS_MTHLC compute statistics; analyze table SA_IMS_MTHUS compute statistics; analyze table SA_CONSUMP_TGT compute statistics; analyze table TEST_TABLE compute statistics; analyze table SA_DOCTOR_CYCLE_EXTRACT compute statistics; analyze table SA_EXCHANGE_ACT compute statistics;
一、SGA 1、Shared pool tunning Shared pool的优化应该放在优先考虑，因为一个cache miss在shared pool中发生比在data buffer中发生导致的成本更高，由于dictionary数据一般比library cache中的数据在内存中保存的时间长，所以关键是library cache的优化。 Gets：（parse）在namespace中查找对象的次数； Pins：（execution）在namespace中读取或执行对象的次数； Reloads：(reparse在执行阶段library cache misses的次数，导致sql需要重新解析。 1）检查v$librarycache中sql area的gethitratio是否超过90％，如果未超过90％，应该检查应用代码，提高应用代码的效率。Select gethitratio from v$librarycache where namespace=’sql area’; 2 v$librarycache中reloads/pins的比率应该小于1％，如果大于1％，应该增加参数shared_pool_size的值。Select sum(pins “executions”,sum(reloads “cache misses”,sum(reloads/sum(pins from v$librarycache; reloads/pins>1%有两种可能，一种是library cache空间不足，一种是sql中引用的对象不合法。 3）shared pool reserved size一般是shared pool size的10％，不能超过50％。 V$shared_pool_reserved中的request misses＝0或没有持续增长，或者free_memory 大于shared pool reserved size的50%，表明shared pool reserved size过大，可以压缩。 4）将大的匿名pl/sql代码块转换成小的匿名pl/sql代码块调用存储过程。 5）从9i开始，可以将execution plan与sql语句一起保存在library cache中，方便进行性能诊断。从v$sql_plan中可以看到execution plans。 6）保留大的对象在shared pool中。大的对象是造成内存碎片的主要原因，为了腾出空间许多小对象需要移出内存，从而影响了用户的性能。因此需要将一些常用的大的对象保留在shared pool中，下列对象需要保留在shared pool中： a. 经常使用的存储过程； b. 经常操作的表上的已编译的触发器 c. Sequence，因为Sequence移出shared pool后可能产生号码丢失。查找没有保存在library cache中的大对象： Select * from v$db_object_cache where sharable_mem>10000 and type in ('PACKAGE','PROCEDURE','FUNCTION','PACKAGE BODY' and kept='NO'; 将这些对象保存在library cache中：Execute dbms_shared_pool.keep(‘package_name’; 对应脚本：dbmspool.sql 7查找是否存在过大的匿名pl/sql代码块。两种解决方案：A．转换成小的匿名块调用存储过程 B．将其保留在shared pool中查找是否存在过
高级数据库技术——期末论文 基于SQL查询的MySQL数据库性能优化研究 ：XX 学号:2014XXXXX 学院：计算机学院
摘要： 查询是数据库系统中最基本也是最常用的一种操作，是否具有较快的执行速度，已成为数据库用户和设计者极其关心的问题。在研究开源数据库管理系统MySQL 查询优化技术的基础上，主要结合传统SQL操作优化、深度分析 MySQL 源代码、现代数据库发展几方面进行诸如参数调优，MySQL关联查询，重写相关规则等容展开优化分析研究。 关键词：查询优化，查询重用，查询重写，计划优化
一、传统SQL查询优化操作 1.选取最适用的字段属性 MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。 另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。 对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。 2.使用连接（JOIN）来代替子查询(Sub-Queries) MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示： DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo ) 使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，
OracleSQL性能优化方法 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访咨询Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序． (6) 7SELECT子句中幸免使用’*’ (6) 8减少访咨询数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访咨询 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14运算记录条数 (9) 15用Where子句替换HA VING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11) 18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要通过反反复复的过程。在数据库建立时，就能依照顾用的需要合理设计分配表空间以及储备参数、内存使用初始化参数，对以后的数据库性能有专门大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积存体会，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用咨询题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表，能够考虑建立分区以提高操作效率。建立分区一样以关键字为分区的标志，也能够以其他字段作为分区的标志，但效率不如关键字高。建立分区的语句在建表时能够进行讲明： create table TABLENAME(
（O管理）ORACLESL性能优化(内部培训资料)
ORACLESQL性能优化系列(一) 1.选用适合的ORACLE优化器 ORACLE的优化器共有3种: a.RULE(基于规则) b.COST(基于成本) c.CHOOSE(选择性) 设置缺省的优化器,可以通过对init.ora文件中OPTIMIZER_MODE参数的各种声明,如RULE,COST,CHOOSE,ALL_ROWS,FIRST_ROWS.你当然也在SQL句级或是会话(session)级对其进行覆盖. 为了使用基于成本的优化器(CBO,Cost-BasedOptimizer),你必须经常运行analyze命令,以增加数据库中的对象统计信息(objectstatistics)的准确性. 如果数据库的优化器模式设置为选择性(CHOOSE),那么实际的优化器模式将和是否运行过analyze命令有关.如果table已经被analyze过,优化器模式将自动成为CBO,反之,数据库将采用RULE形式的优化器. 在缺省情况下,ORACLE采用CHOOSE优化器,为了避免那些不必要的全表扫描(fulltablescan),你必须尽量避免使用CHOOSE优化器,而直接采用基于规则或者基于成本的优化器.
2.访问Table的方式 ORACLE采用两种访问表中记录的方式: a.全表扫描 全表扫描就是顺序地访问表中每条记录.ORACLE采用一次读入多个数据块(databaseblock)的方式优化全表扫描. b.通过ROWID访问表 你可以采用基于ROWID的访问方式情况,提高访问表的效率,,ROWID包含了表中记录的物理位置信息..ORACLE采用索引(INDEX)实现了数据和存放数据的物理位置(ROWID)之间的联系.通常索引提供了快速访问ROWID的方法,因此那些基于索引列的查询就可以得到性能上的提高. 3.共享SQL语句 为了不重复解析相同的SQL语句,在第一次解析之后,ORACLE将SQL语句存放在内存中.这块位于系统全局区域SGA(systemglobalarea)的共享池(sharedbufferpool)中的内存可以被所有的数据库用户共享.因此,当你执行一个SQL语句(有时被称为一个游标)时,如果它和之前的执行过的语句完全相同,ORACLE就能很快获得已经被解析的语句以及最好的执行路
Centos6.5操作系统下，oracle数据库性能调优 1.在liunx下对数据库性能调优，首先要考虑操作系统级别的问题如：如CPU、内存、IO的瓶颈，再考虑oracle本身参数的设置。 1. 可通过top 命令判断是否为CPU瓶颈，如果oracle进程占用CPU过多，可考虑为CPU的问题。 目前我们针对的主要是内存和磁盘的问题。 2.Oracle数据库内存参数的优化 ?与oracle相关的系统内核参数 ?SGA、PGA参数设置 （1）系统内核参数 修改/etc/sysctl.conf 这个文件，加入以下的语句： kernel.shmmax = 2147483648 kernel.shmmni = 4096 kernel.shmall = 2097152 kernel.sem = 250 32000 100 128 fs.file-max = 65536 参数依次为： Kernel.shmmax:共享内存段的最大尺寸（以字节为单位）。 Kernel.shmmni：系统中共享内存段的最大数量。 Kernel.shmall：共享内存总量，以页为单位。 fs.file-max：文件句柄数，表示在Linux系统中可以打开的文件数量。 net.ipv4.ip_local_port_range：应用程序可使用的IPv4端口范围。 可通过sysctl -p 查看内核参数的值，请确认各个内核参数只有一个，避免出现一个内核参数出现好几次的情况，导致正确的参数别覆盖。
需要注意的几个问题 关于Kernel.shmmax Oracle SGA 由共享内存组成，如果错误设置SHMMAX可能会限制SGA 的大小，SHMMAX设置不足可能会导致以下问题：ORA-27123:unable to attach to shared memory segment，如果该参数设置小于Oracle SGA设置，那么SGA就会被分配多个共享内存段。这在繁忙的系统中可能成为性能负担，带来系统问题。 Oracle建议Kernel.shmmax最好大于sga，以让oracle共享内存区SGA在一个共享内存段中，从而提高性能。 Oracle 11g实现了数据库所有内存块的全自动化管理，使得动态管理SGA和PGA成为现实。 日志文件及表空间文件的大小及位置也是影响性能的一个因素，排查过程如下。 应用 iotop -ao 命令查看oracle对磁盘读写对资源的占用情况， ora_lgwr_first进行对磁盘的访问较多。 使用
Oracle SQL性能优化方法探讨 Oracle性能优化方法(SQL篇) (1) 1综述 (2) 2表分区的应用 (2) 3访问Table的方式 (3) 4共享SQL语句 (3) 5选择最有效率的表名顺序 (5) 6WHERE子句中的连接顺序． (6) 7SELECT子句中幸免使用’*’ (6) 8减少访问数据库的次数 (6) 9使用DECODE函数来减少处理时刻 (7) 10整合简单,无关联的数据库访问 (8) 11删除重复记录 (8) 12用TRUNCATE替代DELETE (9) 13尽量多使用COMMIT (9) 14计算记录条数 (9) 15用Where子句替换HAVING子句 (9) 16减少对表的查询 (10) 17通过内部函数提高SQL效率 (11)
18使用表的不名(Alias) (12) 19用EXISTS替代IN (12) 20用NOT EXISTS替代NOT IN (13) 21识不低效执行的SQL语句 (13) 22使用TKPROF 工具来查询SQL性能状态 (14) 23用EXPLAIN PLAN 分析SQL语句 (14) 24实时批量的处理 (16)
1综述 ORACLE数据库的性能调整是个重要，却又有难度的话题，如何有效地进行调整，需要通过反反复复的过程。在数据库建立时，就能依照顾用的需要合理设计分配表空间以及存储参数、内存使用初始化参数，对以后的数据库性能有专门大的益处，建立好后，又需要在应用中不断进行应用程序的优化和调整，这需要在大量的实践工作中不断地积存经验，从而更好地进行数据库的调优。 数据库性能调优的方法 ●调整内存 ●调整I/O ●调整资源的争用问题 ●调整操作系统参数 ●调整数据库的设计 ●调整应用程序 本文针对应用程序的调整，来讲明对数据库性能如何进行优化。 2表分区的应用 关于海量数据的表，能够考虑建立分区以提高操作效率。建
Oracle性能调优原则 任何事情都有它的源头，要解决问题，也得从源头开始，影响ORACLE性能的源头非常多，主要包括如下方面:数据库的硬件配置:CPU、内存、网络条件1. CPU:在任何机器中CPU的数据处理能力往往是衡量计算机性能的一个标志，并且ORACLE是一个提供并行能力的数据库系统，在CPU方面的要求就更高了，如果运行队列数目超过了CPU处理的数目，性能就会下降，我们要解决的问题就是要适当增加CPU的数量了，当然我们还可以将需要许多资源的进程KILL掉;2. 内存:衡量机器性能的另外一个指标就是内存的多少了，在ORACLE中内存和我们在建数据库中的交换区进行数据的交换，读数据时，磁盘I/O必须等待物理I/O操作完成，在出现ORACLE 的内存瓶颈时，我们第一个要考虑的是增加内存，由于I/O的响应时间是影响ORACLE性能的主要参数，我将在这方面进行详细的讲解3. 网络条件:NET*SQL负责数据在网络上的来往，大量的SQL会令网络速度变慢。比如10M的网卡和100的网卡就对NET*SQL有非常明显的影响，还有交换机、集线器等等网络设备的性能对网络的影响很明显，建议在任何网络中不要试图用3个集线器来将网段互联。OS参数的设置下表给出了OS的参数设置及说明，DBA可以根据实际需要对这些参数进行设置内核参数名说明bufpages对buffer空间不按静态分配，采用动态分配，使bufpages值随nbuf一起对
buffer空间进行动态分配。Create_fastlinks对HFS文件系统允许快速符号链接dbc_max_pct加大最大动态buffer空间所占物理内存的百分比，以满足应用系统的读写命中率的需要。Dbc_min_pct设置最小动态buffer空间所占物理内存的百分比desfree提高开始交换操作的最低空闲内存下限，保障系统的稳定性，防止出现不可预见的系统崩溃(Crash)。Fs_async允许进行磁盘异步操作，提高CPU 和磁盘的利用率lotsfree提高系统解除换页操作的空闲内存的上限值，保证应用程序有足够的可用内存空间。Maxdsiz针对系统数据量大的特点，加大最大数据段的大小，保证应用的需要。(32位)maxdsiz_64bitmaximum process data segment size for 64_bitMaxssiz加大最大堆栈段的大小。(32_bit)maxssiz_64bit加大最大堆栈段的大小。(64_bit)Maxtsiz提高最大代码段大小，满足应用要求maxtsiz_64bit原值过大，应调小Minfree提高停止交换操作的自由内存的上限Shmem允许进行内存共享，以提高内存的利用率Shmmax设置最大共享内存段的大小，完全满足目前的需要Timeslice由于系统的瓶颈主要反映在磁盘I/O上，因此降低时间片的大小，一方面可避免因磁盘I/O不畅造成CPU的等待，从而提高了CPU的综合利用率。另一方面减少了进程的阻塞量。Unlockable_mem提高了不可锁内存的大小，使可用于换页和交换的内存空间扩大,用以满足系统对内存管理的要求。用户SQL质量以上讲的都是硬件方面的东西，在条件有限的条件下，我们可以调整应用程序的SQL质量:1. 不要进行全表扫描(Full Table Scan):全表扫描
理解Oracle的日志机制 ? Oracle的日志是用来记录用户对数据库的改变，这样，当出现服务器硬件故障或者用户错误而丢失数据时，可以通过重做这些日志来恢复已提交的事务，Oracle日志机制包含以下组件： ?日志缓存SGA的一部分，用于缓存服务器进程产生的日志，包括DML和DDL； ? LGWR进程这个后台进程负责将日志缓存的数据写到联机日志文件，每个实例只有一个； ?数据库检查点检查点用于同步数据文件和日志文件，一个检查点事件的完成，代表在这个事件开始之前发生的所有对数据文件的改变都已实际记录到了数据文件，数据库在这个时间点是一致的，在实例恢复的时候，只有在最后一个检查点之后的日志才需要重做； ?联机日志文件用于存放从日志缓存中写出的日志数据，每个数据库最少需要两个日志文件，当前日志文件填满以后，发生日志切换，然后才可以继续写下一个日志文件； ?日志归档LGWR写满所有组的联机日志文件以后，会回头再写第一个组的日志文件，在非归档模式下，被重用的日志文件中的日志会被丢弃，在归档模式下，日志文件被重用前会被ARC0进程复制到归档日志文件； ? 一些可选的日志机制，如归档和Standby，因为附加的I/O会降低系统的性能，同时提供了可靠的灾难恢复能力，不建议因这些性能的下降而关闭生产系统的归档功能。 调整日志缓存 ? 日志缓存的管理机制可以类似理解成一个漏斗，日志数据不断地从漏斗上方加入，然后偶尔打开漏斗下方的开关将加入的数据清空，这个开关就是LGWR进程，为了日志缓存有空间容纳不断加进来的日志数据，LGWR在下面列出的任何一个条件下都会执行写出日志缓存的操作： ?应用程序发出Commit命令时； ?三秒间隔已到时； ?日志缓存三分之一满时； ?日志缓存达到1M时； ?数据库检查点发生时； ? 测量日志缓存的性能通过服务器进程放置日志条到日志缓存时发生等待的次数和时间来测量； Select Name, Value From V$sysstat Where Name In ('redo entries', 'redo buffer allocation retries','redo log space requests'); redo entries 服务器进程放进日志缓存的日志条的总数量； redo buffer allocation retries 服务器放置日志条时必须等待然后再重试的次数； redo log space requests LGWR进程写出日志缓存时等待日志切换的次数； 这个查询用于计算日志缓存重试率，这个比率应该小于百分之一； Select Retries.Value / Entries.Value "Redo log Buffer Retry Ratio" From V$sysstat Entries, V$sysstat Retries Where https://www.doczj.com/doc/3511883627.html, = 'redo entries' And https://www.doczj.com/doc/3511883627.html, = 'redo buffer allocation retries'; 这个查询用来显示哪些会话的LGWR正在进行写等待；
1数据库设计 要在良好的SQLServer方案中实现最优的性能，最关键的是要有1个很好的数据库设计方案。在实际工作中，许多SQLServer方案往往是由于数据库设计得不好导致性能很差。所以，要实现良好的数据库设计就必须考虑这些问题。 1.1逻辑库规范化问题 一般来说，逻辑数据库设计会满足规范化的前3级标准： 1.第1规范：没有重复的组或多值的列。 2.第2规范：每个非关键字段必须依赖于主关键字，不能依赖于1个组合式主关键字的某些组成部分。 3.第3规范：1个非关键字段不能依赖于另1个非关键字段。 遵守这些规则的设计会产生较少的列和更多的表，因而也就减少了数据冗余，也减少了用于存储数据的页。但表关系也许需要通过复杂的合并来处理，这样会降低系统的性能。某种程度上的非规范化可以改善系统的性能，非规范化过程可以根据性能方面不同的考虑用多种不同的方法进行，但以下方法经实践验证往往能提高性能。 1.如果规范化设计产生了许多4路或更多路合并关系，就可以考虑在数据库实体中加入重复属性。 2.常用的计算字段可以考虑存储到数据库实体中。 比如某一个项目的计划中有计划表，其字段为：项目编号、年初计划、二次计划、调整计划、补列计划…，而计划总数是用户经常需要在查询和报表中用到的，在表的记录量很大时，有必要把计划总数作为1个独立的字段加入到表中。这里可以采用触发器以在客户端保持数据的一致性。 3.重新定义实体以减少外部属性数据或行数据的开支。相应的非规范化类型是： 把1个实体分割成2个表。这样就把频繁被访问的数据同较少被访问的数据分开了。这种方法要求在每个表中复制首要关键字。这样产生的设计有利于并行处理，并将产生列数较少的表。 把1个实体分割成2个表。这种方法适用于那些将包含大量数据的实体。在应用中常要保留历史记录，但是历史记录很少用到。因此可以把频繁被访问的数据同较少被访问的历史数据分开。而且如果数据行是作为子集被逻辑工作组访问的，那么这种方法也是很有好处的。1.2生成物理数据库 要想正确选择基本物理实现策略，必须懂得数据库访问格式和硬件资源的操作特点，主要是内存和磁盘子系统I/O。这是一个范围广泛的话题，但以下的准则可能会有所帮助。 1.与每个表列相关的数据类型应该反映数据所需的最小存储空间，特别是对于被索引的列更是如此。比如能使用smallint类型就不要用integer类型，这样索引字段可以被更快地读取，而且可以在1个数据页上放置更多的数据行，因而也就减少了I/O操作。 2.把1个表放在某个物理设备上，再通过SQLServer段把它的不分簇索引放在1个不同的物理设备上，这样能提高性能。尤其是系统采用了多个智能型磁盘控制器和数据分离技术的情况下，这样做的好处更加明显。 3.用SQLServer段把一个频繁使用的大表分割开，并放在2个单独的智能型磁盘控制器的数据库设备上，这样也可以提高性能。因为有多个磁头在查找，所以数据分离也能提高性能。 4.用SQLServer段把文本或图像列的数据存放在1个单独的物理设备上可以提高性能。1个专用的智能型的控制器能进一步提高性能。 2与SQLServer相关的硬件系统 与SQLServer有关的硬件设计包括系统处理器、内存、磁盘子系统和网络，这4个部分基本
个人理解，数据库性能最关键的因素在于IO，因为操作内存是快速的，但是读写磁盘是速度很慢的，优化数据库最关键的问题在于减少磁盘的IO，就个人理解应该分为物理的和逻辑的优化，物理的是指oracle产品本身的一些优化，逻辑优化是指应用程序级别的优化物理优化： 一、优化内存
V$ROWCACHE视图结构
3.管理员可以通过下述语句来查看数据缓冲区的使用情况 select name,value from v$sysstat where name in ('db block gets', 'consistent gets ', 'physical reads'); 数据缓冲区使用命中率（physical reads除以db block gets加consistent gets之和)一定要小于10%，否则需要增加数据缓冲区大小 4.管理员可以通过执行下述语句，查看日志缓冲区的使用情况 select name,value from v$sysstat where name in ('redo entries','redo log space requests') 根据查询出的结果可以计算出日志缓冲区的申请失败率：requests除以entries 申请失败率应该解决与0，否则说明日志缓冲区开设太小，需要增加Oracle数据库的日志缓冲区 二、物理I/0的优化 1.在磁盘上建立数据文件前首先运行磁盘碎片整理程序 为了安全地整理磁盘碎片，需关闭打开数据文件的实例，并且停止服务。如果有足够的连续磁盘空间建立数据文件，那么就容易避免数据文件产生碎片。 2.不要使用磁盘压缩（Oracle文件不支持磁盘压缩） 3.不要使用磁盘加密
Oracle性能优化学习心得 一，优化总的原则 1，查看系统的使用情况 2，查看SGA分配情况，结合系统具体情况进行分析。 3，表的设计分析 4，SQL语句分析 实施要则 1，查看系统的使用情况，CPU占用，内存，I/O读取等 Oracle10G提供的Oracle Enterprise Manager图形化工具中的ADDM 和SQL Tuning Advisor等可以方便的查看系统状况 2，OPS上负载均衡，不同查询用不同Instance 3，提供脚本查看SGA使用情况 4，分析SQL执行情况（trace及其他工具） 实施细节 1，外部调整：我们应该记住Oracle并不是单独运行的。因此我们将查看一下通过调整Oracle服务器以得到高的性能。 2，Row re-sequencing以减少磁盘I/O：我们应该懂得Oracle调优最重要的目标是减少I/O。 3，Oracle SQL调整。Oracle SQL调整是Oracle调整中最重要的领域之一，只要通过一些简单的SQL调优规则就可以大幅度地提升SQL语句的性能，这是一点都不奇怪的。 4，调整Oracle排序：排序对于Oracle性能也是有很大影响的。 5，调整Oracle的竞争：表和索引的参数设置对于UPDATE和INSERT的性能有很大的影响。 二，调优分类： 对Oracle数据库进行性能调整时，应当按照一定的顺序进行，因为系统在前面步骤中进行的调整可以避免后面的一些不必要调整或者代价很大的调整。一般来说可以从两个阶段入手： 1、设计阶段：对其逻辑结构和物理结构进行优化设计，使之在满足需求条件的情况下,系统性能达到最佳，系统开销达到最小； 2、数据库运行阶段：采取操作系统级、数据库级的一些优化措施来使系统性能最佳； ㈠设计阶段： A，数据库设计优化 较多修改较少查询的数据和较多查询较少修改的数据分别对待。 a，结构优化 1，根据应用程序进行数据库设计。 即应用程序采用的是传统的C/S两层体系结构，还是B/W/D三层体系结构。不同的应用程序体系结构要求的数据库资源是不同的。 2，遵循3大范式规范化数据结构，减少不必要的冗余。 3，反规范设计，增加必要冗余，提高查询速度。 4，针对变化较少的数据，合理创建临时表和视图，需注意对临时表和视图的及时同步更新
基于ＳＱＬＳｅｒｖｅｒ２０００的数据库性能调整技术摘要：本文对数据库应用系统的各个部分特别是数据库服务器、SQL 语句、存储过程等的性能调整作了大量的分析和试验，提出了一些具体的性能调整方法和措施，并取得较好的应用效果。 关键词：SQL;数据库;性能优化 一、基于SQLServer2000的数据库性能调整 1.系统规划 数据库服务器是整个数据库应用系统的核心，它的性能高低直接影响整个系统的性能。SQL Server2000数据库的很多方面都可以被优化或调整，以便给予系统更好的性能，诸如硬件、SQL Server配置、数据库设计、SQL语句、SQL索引、复制、备份与恢复及其他。 2.优化SQL语句 SQL优化的实质就是在结果正确的条件下，用优化器可以识别的语句，充份利用索引，减少表扫描的I/O次数，尽量避免表搜索的发生。实在SQL的性能优化是一个复杂的过程，上述这些只是在应用层次的一种体现，深进研究还会涉及数据库层的资源配置、网络层的流量控制以及操纵系统层的总体设计。在这里就不展开了，在第五章将有专题讨论。 3.存储过程调整 SQL Server存储过程是用Transact-SQL语句PROCEDURE创建的，
并可用ALTER PROCEDURE语句进行修改。存储过程定义包含两个主要组成部分：过程名称及其参数的说明，以及过程的主体所有设计优良的Microsoft SQL ServerTM 2000应用程序都应当使用存储过程。不论是否将应用程序的业务逻辑写进存储过程都应如此。 4.高性能备份与恢复 需要确定数据的可用性要求，以便选择适当的备份和还原策略。总体备份策略定义备份的类型和频率以及所需的硬件特性和速度。测试备份和恢复过程。测试有助于确保拥有从各种故障中恢复所需的备份，并且认真正的故障发生时可以快速平稳地执行恢复过程。 5.用户治理 工程设计企业传统的组织结构按专业及职责设置，是面向部分的层次治理结构。这种组织结构治理层次多，各个机构间协调复杂，造成了信息交流和传递困难，设计周期长等题目。 二、优化SQL语句和存储过程 数据库调整中一个很重要的方面就是应用程序的调整，关键在于SQL语句的优化和存储过程的应用。本章结合具体的项目实践，讨论了一些关于SQL语句的优化和存储过程的应用的方法和措施。 1.优化SQL语句 SQL优化的实质就是在结果正确的条件下，用优化器可以识别的语句，充份利用索引，减少表扫描的次数，尽量避免表搜索的发生。
ORACLE SQL性能优化 我要讲的题目是Oracle SQL性能优化，只是Oracle性能优化中的一项。Oracle的性能优化包含很多方面，比如调整物理存取，调整逻辑存取，调整内存使用，减少网络流量等。这里选择SQL性能优化是因为这部分内容我们测试人员最容易接触到，另外开发人员写SQL脚本时有时很随意，不知不觉就会造成程序性能上的下降。 1．选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名,因此FROM子句中写在最后的表(基础表 driving table)将被最先处理. 在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基 础表.当ORACLE处理多个表时, 会运用排序及合并的方式连接它们.首先,扫描第一个表(FROM子句中最后的那个表)并对记录进行派序,然后扫描 第二个表(FROM子句中最后第二个表),最后将所有从第二个表中检索出 的记录与第一个表中合适记录进行合并. 例如: 表 TAB1 16,384 条记录 表 TAB2 1 条记录 选择TAB2作为基础表 (最好的方法) select count(*) from tab1,tab2 执行时间0.96秒 选择TAB2作为基础表 (不佳的方法)
select count(*) from tab2,tab1 执行时间26.09秒 如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. 例如: EMP表描述了LOCATION表和CATEGORY表的交集. SELECT * FROM LOCATION L , CATEGORY C, EMP E WHERE E.EMP_NO BETWEEN 1000 AND 2000 AND E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN 将比下列SQL更有效率 SELECT * FROM EMP E , LOCATION L , CATEGORY C WHERE E.CAT_NO = C.CAT_NO AND E.LOCN = L.LOCN AND E.EMP_NO BETWEEN 1000 AND 2000 2．WHERE子句中的连接顺序． ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾.
个人理解，数据库性能最关键的因素在于IO，因为操作存是快速的，但是读写磁盘是速度很慢的，优化数据库最关键的问题在于减少磁盘的IO，就个人理解应该分为物理的和逻辑的优化，物理的是指oracle产品本身的一些优化，逻辑优化是指应用程序级别的优化 物理优化： 一、优化存
3.管理员可以通过下述语句来查看数据缓冲区的使用情况 select name,value from v$sysstat where name in('db block gets','consistent gets','physica l reads'); 数据缓冲区使用命中率（physical reads除以db block gets加consistent gets之和)一定要小于10%，否则需要增加数据缓冲区大小 4.管理员可以通过执行下述语句，查看日志缓冲区的使用情况 select name,value from v$sysstat where name in ('redo entries','redo log space requests') 根据查询出的结果可以计算出日志缓冲区的申请失败率：requests除以entries 申请失败率应该解决与0，否则说明日志缓冲区开设太小，需要增加Oracle数据库的日志缓冲区 二、物理I/0的优化 1.在磁盘上建立数据文件前首先运行磁盘碎片整理程序 为了安全地整理磁盘碎片，需关闭打开数据文件的实例，并且停止服务。如果有足够的连续磁盘空间建立数据文件，那么就容易避免数据文件产生碎片。 2.不要使用磁盘压缩（Oracle文件不支持磁盘压缩） 3.不要使用磁盘加密 加密像磁盘压缩一样加了一个处理层，降低磁盘读写速度。如果担心自己的数据可能泄露，可以使用dbms_obfuscation包和label security选择性地加密数据的敏感部分 4.使用RAID raid使用应注意： 选择硬件raid超过软件raid；日志文件不要放在raid5卷上，因为raid5读性能高而写性能差；把日志文件和归档日志放在与控制文件和数据文件分离的磁盘控制系统上 5.分离页面交换文件到多个磁盘物理卷 跨越至少两个磁盘建立两个页面文件。可以建立四个页面文件并在性能上受益，确保所有页面文件的大小之和至少是物理存的两倍。
Oracle Statspack报告中各项指标含义详解！ Data Buffer Hit Ratio#<#90# 数据块在数据缓冲区中的命中率，通常应该在90%以上，否则考虑加大db_block_buffers(9i 以上可是db_cache_size) Buffer Nowait Ratio#<#99# 在缓冲区中获取buffer 的未等待比率 Library Hit Ratio#<#98# 主要代表着sql在共享区的命中率，通常在98%以上 In Memory Sort Ratio#<#0# 如果过低说明有大量的排序在临时表空间中进行，可尝试增加 sort_area_size Redo Nowait Ratio#<#98# 写日志的不等待比率,太低可调整log_buffer(增加)和 _log_io_size(减小，默认为1/3*log_buffer/log_block_size,使得 _log_io_size 为合适的值，比如128k/log_block_size) Soft Parse Ratio#<#90# 近似当作sql在共享区的命中率，通常高代表使用了绑定变量,太低需要调整应用使用绑定变量，或者参考cursor_sharing = force (9i 中增加了similar ) Latch Hit Ratio#<#99# 内部结构维护锁命中率，高于99%,通常低是因为shared_pool_size过大和没有使用绑定变量导致硬解析过多，可参考 _spin_count 参数设置
Percent Non-Parse CPU#<#95# 查询实际运行时间/(查询实际运行时间+sql解析时间)，太低表示解析消耗时间过长 Percent Parse CPU to Parse Elapsed#<#90# 解析实际所用时间/(解析实际所用时间+解析中等待资源时间),越高越好 Execute to Parse Percent#<#10# 该值越高表示一次解析后被重复执行的次数越多，如果过低可以考虑设置 session_cached_cursors > 0 Memory Usage Percent#<#75# 共享池的使用率，应该稳定在75%--90%之间，太小浪费内存，太大则显内存不足 Percent of SQLs with Execution>1#<#40# 执行次数大于1的sql的比率（若太小可能是没有使用绑定变量） Percent of Memory for SQl with Execution>1#<#0# 执行次数大于1的sql消耗内存/(所有sql消耗内存) Instance Load Profile Redo Size/Sec#>#100000# 每秒产生的日志大小（单位字节），可标志数据库任务的繁重与否 Redo Size/Tx#>#0# 平均每个事务的日志生成量 Logical Reads/Sec(逻辑读)#>#0#