当前位置：首页 > 范文大全 > 实用文>disablelogging对于性能的影响数据库

disablelogging对于性能的影响数据库

2024-03-16 08:11:17 收藏本文下载本文

“wszxsm”通过精心收集，向本站投稿了5篇disablelogging对于性能的影响数据库，以下是小编整理后的disablelogging对于性能的影响数据库，希望能够帮助到大家。

篇1：disablelogging对于性能的影响数据库

设置了_disable_logging参数,可以禁用日志的生成,从而提高某些测试的性能 . 以下测试,纯属测试目的,其他内容请参考本站其他文章: www.eygle.com/archives//04/more_about_disable_logging.html 禁用日志情况下: SQL connect / as sysdba Connect

设置了_disable_logging参数,可以禁用日志的生成,从而提高某些测试的性能.

以下测试,纯属测试目的,其他内容请参考本站其他文章:

www.eygle.com/archives/2006/04/more_about_disable_logging.html

禁用日志情况下:

SQL>connect / as sysdba

Connected.

SQL>shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL>startup

ORACLE instance started.

Total System Global Area 286755168 bytes

Fixed Size 731488 bytes

Variable Size 167772160 bytes

Database Buffers 117440512 bytes

Redo Buffers 811008 bytes

Database mounted.

Database opened.

SQL>connect eygle/eygle

Connected.

SQL>show parameter disable

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

_disable_logging boolean TRUE

测试创建100万数据表:

SQL>create table test as select * from dba_objects where 1=0;

Table created.

SQL>set timing on

SQL>begin

2 for i in 1 .. 10000 loop

3 insert into test select * from dba_objects where rownum < 101;

4 commit;

5 end loop;

6 end;

7 /

PL/SQL procedure suclearcase/“ target=”_blank“ >ccessfully completed.

Elapsed: 00:00:40.46

SQL>truncate table test;

Table truncated.

Elapsed: 00:00:52.72

大约时间用了40秒.

再看正常日志生成下:

SQL>connect / as sysdba

Connected.

SQL>alter system set ”_disable_logging“=false;

System altered.

Elapsed: 00:00:00.05

SQL>shutdown immediate;

Database closed.

Database dismounted.

ORACLE instance shut down.

SQL>startup

ORACLE instance started.

Total System Global Area 286755168 bytes

Fixed Size 731488 bytes

Variable Size 167772160 bytes

Database Buffers 117440512 bytes

Redo Buffers 811008 bytes

Database mounted.

Database opened.

SQL>show parameter disable

NAME TYPE VALUE

------------------------------------ ----------- ------------------------------

_disable_logging boolean FALSE

SQL>connect eygle/eygle

Connected.

SQL>set timing on

SQL>

SQL>begin

2 for i in 1 .. 10000 loop

3 insert into test select * from dba_objects where rownum < 101;

4 commit;

5 end loop;

6 end;

7 /

PL/SQL procedure successfully completed.

Elapsed: 00:01:54.04

SQL>

SQL>truncate table test;

Table truncated.

Elapsed: 00:01:01.56

此时大约用时1分54秒.

两者差距为: 114 / 40 = 2.85 倍.

我们可以看出两者的差距是显著的.不作过多测试了,就此打住.大家有兴趣的可以自己测试一下.

以上测试的环境为:

SQL>select * from v$version;

BANNER

----------------------------------------------------------------

Oracle9i Enterprise Edition Release 9.2.0.4.0 - 64bit Production

PL/SQL Release 9.2.0.4.0 - Production

CORE 9.2.0.3.0 Production

TNS for Solaris: Version 9.2.0.4.0 - Production

NLSRTL Version 9.2.0.4.0 - Production

原文地址：www.eygle.com/archives/2006/04/disable_logging_performance.html

原文转自：www.ltesting.net

篇2：影响SQLserver性能的关键三个方面数据库

1 逻辑数据库和表的设计数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心，一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基

1 逻辑数据库和表的设计

数据库的逻辑设计、包括表与表之间的关系是优化关系型数据库性能的核心。一个好的逻辑数据库设计可以为优化数据库和应用程序打下良好的基础。

标准化的数据库逻辑设计包括用多的、有相互关系的窄表来代替很多列的长数据表。下面是一些使用标准化

表的一些好处。

A:由于表窄，因此可以使排序和建立索引更为迅速

B:由于多表，所以多镞的索引成为可能

C:更窄更紧凑的索引

D:每个表中可以有少一些的索引，因此可以提高insert update delete等的速度，因为这些操作在索引

多的情况下会对系统性能产生很大的影响

E:更少的空值和更少的多余值，增加了数据库的紧凑性

由于标准化，所以会增加了在获取数据时引用表的数目和其间的连接关系的复杂性。太多的表和复杂的连接关系会降低服务器的性能，因此在这两者之间需要综合考虑。

定义具有相关关系的主键和外来键时应该注意的事项主要是：用于连接多表的主键和参考的键要有相同的数据类型。

2 索引的设计

A:尽量避免表扫描

检查你的查询语句的where子句，因为这是优化器重要关注的地方。包含在where里面的每一列（column)都是可能的侯选索引，为能达到最优的性能，考虑在下面给出的例子：对于在where子句中给出了column1这个列。

下面的两个条件可以提高索引的优化查询性能！

第一：在表中的column1列上有一个单索引

第二：在表中有多索引，但是column1是第一个索引的列

避免定义多索引而column1是第二个或后面的索引，这样的索引不能优化服务器性能

例如：下面的例子用了pubs数据库。

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'

按下面几个列上建立的索引将会是对优化器有用的索引

?au_lname

?au_lname, au_fname

而在下面几个列上建立的索引将不会对优化器起到好的作用

?au_address

?au_fname, au_lname

考虑使用窄的索引在一个或两个列上，窄索引比多索引和复合索引更能有效。用窄的索引，在每一页上

将会有更多的行和更少的索引级别（相对与多索引和复合索引而言），这将推进系统性能。

对于多列索引，SQL Server维持一个在所有列的索引上的密度统计（用于联合）和在第一个索引上的

histogram（柱状图）统计。根据统计结果，如果在复合索引上的第一个索引很少被选择使用，那么优化器对很多查询请求将不会使用索引。

有用的索引会提高select语句的性能，包括insert,uodate,delete。

但是，由于改变一个表的内容，将会影响索引。每一个insert,update,delete语句将会使性能下降一些。实验表明，不要在一个单表上用大量的索引，不要在共享的列上（指在多表中用了参考约束）使用重叠的索引。

在某一列上检查唯一的数据的个数，比较它与表中数据的行数做一个比较。这就是数据的选择性，这比较结果将会帮助你决定是否将某一列作为侯选的索引列，如果需要，建哪一种索引。你可以用下面的查询语句返回某一列的不同值的数目。

select count(distinct cloumn_name) from table_name

假设column_name是一个10000行的表，则看column_name返回值来决定是否应该使用，及应该使用什么索引。

Unique values Index

5000 Nonclustered index

20 Clustered index

3 No index

镞索引和非镞索引的选择

<1:>镞索引是行的物理顺序和索引的顺序是一致的，

页级，低层等索引的各个级别上都包含实际的数据页。一个表只能是有一个镞索引。由于update,delete语句要求相对多一些的读操作，因此镞索引常常能加速这样的操作。在至少有一个索引的表中，你应该有一个镞索引。

在下面的几个情况下，你可以考虑用镞索引：

例如：某列包括的不同值的个数是有限的（但是不是极少的）

顾客表的州名列有50个左右的不同州名的缩写值，可以使用镞索引。

例如：对返回一定范围内值的列可以使用镞索引，比如用between,>,>=,<,<=等等来对列进行操作的列上。

select * from sales where ord_date between '5/1/93' and '6/1/93'

例如：对查询时返回大量结果的列可以使用镞索引。

SELECT * FROM phonebook WHERE last_name = 'Smith'

当有大量的行正在入表中时，要避免在本表一个自然增长（例如，identity列）的列上建立镞索引。如果你建立了镞的索引，那么insert的性能就会大大降低。因为每一个插入的行必须到表的最后，表的最后一个数据页。

当一个数据正在入（这时这个数据页是被锁定的），所有的其他插入行必须等待直到当前的插入已经结束。

一个索引的叶级页中包括实际的数据页，并且在硬盘上的数据页的次序是跟镞索引的逻辑次序一样的。

<2:>一个非镞的索引就是行的物理次序与索引的次序是不同的。一个非镞索引的叶级包含了指向行数据页的指针。

在一个表中可以有多个非镞索引，你可以在以下几个情况下考虑使用非镞索引。

在有很多不同值的列上可以考虑使用非镞索引

例如：一个part_id列在一个part表中

select * from employee where emp_id = 'pcm9809f'

查询语句中用order by 子句的列上可以考虑使用镞索引

3 查询语句的设计

SQL Server优化器通过分析查询语句，自动对查询进行优化并决定最有效的执行方案。优化器分析查询语句来决定那个子句可以被优化，并针对可以被优化查询的子句来选择有用的索引。最后优化器比较所有可能的执行方案并选择最有效的一个方案出来。

在执行一个查询时，用一个where子句来限制必须处理的行数，除非完全需要，否则应该避免在一个表中无限制地读并处理所有的行。

例如下面的例子，

select qty from sales where stor_id=7131

是很有效的比下面这个无限制的查询

select qty from sales

避免给客户的最后数据选择返回大量的结果集。允许SQL Server运行满足它目的的函数限制结果集的大小是更有效的。

这能减少网络I/O并能提高多用户的相关并发时的应用程序性能。因为优化器关注的焦点就是where子句的查询，以利用有用的索引。在表中的每一个索引都可能成为包括在where子句中的侯选索引。为了最好的性能可以遵照下面的用于一个给定列column1的索引。

第一：在表中的column1列上有一个单索引

第二：在表中有多索引，但是column1是第一个索引的列不要在where子句中使用没有column1列索引的查询语句，并避免在where子句用一个多索引的非第一个索引的索引。

这时多索引是没有用的。

For example, given a multicolumn index on the au_lname, au_fname columns of the authors table in

the pubs database,

下面这个query语句利用了au_lname上的索引

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'

AND au_fname = 'Johnson'

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_lname = 'White'

下面这个查询没有利用索引，因为他使用了多索引的非第一个索引的索引

SELECT au_id, au_lname, au_fname FROM authors

WHERE au_fname = 'Johnson'

原文转自：www.ltesting.net

篇3：不让链化现象影响数据库性能

正常情况下往表中新建记录时，数据库系统会将数据写入到块并会像这行记录提供一个ROWID值，这个值记录了这条记录在硬盘上存储的位置。在更新某条记录的时候，也是如此。数据库系统会根据ROWID的值将需要更新的记录从硬盘中读取到块中;然后更新完毕后，再将块中的记录保存到硬盘对应的位置。更新过程中，ROWID列的值通常情况下不会改变。

但是如果一个块的容量不能够容纳一条记录。也就是会所，当单个数据块没有足够的空间来保存新建的一行记录或者更新的某行记录时，就会发生链化现象。到一个数据库的容量不足以容纳一条记录时，那么数据库就不得不动用更多的数据块来保存这条记录。在Oracle数据库中，如果某条记录需要利用多个数据库来保存，我们往往把这行记录叫做链化行。而在访问一行记录时，如果需要访问多个数据块，则会比访问单个数据块需要耗费更多的服务器资源，会大大降低数据库性能。我们把这种因为链化行而导致的数据库性能下降的现象叫做链化现象。根据专家统计，严重的话，链化现象可能降低数据库10%的性能，甚至更多。所以数据库管理员如果在数据库部署中，能够有效避免链化现象，那么就可以在很大程度上提升数据库的性能

一、如何判断是否有链化现象的存在?

那么数据库管理员该如何判断数据库中是否有链化现象的存在呢?如果没有工具，光凭数据库管理员的眼力或者经验的话，是很难判断的。数据库管理员必须找一个顺手的工具。其实Oracle数据库设计这已经预计到这个问题对于数据库性能的不利影响。为此在数据库中已经提供了追踪、分析链化现象的工具。在 Oracle数据库安装主目录的/rdbms/admin下有一个脚本文件，名字叫做utlchain.sql。这是Oracle数据库自带的一个脚本文件。我们可以利用文本编辑器等工具来打开这个脚本文件，可以看到这个脚本文件主要是用来创建一个表，用来保存分析脚本现象所需要的内容。

第一步：创建所需要的表。

首先，数据库管理元需要执行Oracle数据库提供的utlchain.sql脚本文件。这个文件位于Oracle主目录下的/rdbms /admin下。这个脚本主要的用途就是建立一个表格。这个表格很有用。数据库系统会把分析的结果保存到这个表中。默认情况下，这个表格在安装数据库时并不会自动生成。如果数据库管理员需要分析数据库中是否存在链化现象，那么就需要手工执行这个脚本文件，以建立这张表格。这张表格中，主要有表名、HEAD_ROWID列等等。

第二步：分析目的表格。

创建上面的表格后，默认情况下里面是没有数据的。因为还没有进行相关的分析。假设现在在数据库中有一个Product的表格，主要用来保存产品信息。现在数据库管理员想要知道，数据库系统在操作这张表格数据的时候，是否存在有链化现象。此时，数据库管理员就需要利用下面的语句来进行分析查询。

Analyze table product list chained rows;

上面这条语句的作用，就是会分析product这张表格。判断这张表格中的记录是否存在在不同的块中。如果这个product表格中，有记录存储在不同的块中，则这条语句就会把相关的结果保存到刚才建立的表中。所以，如果数据库管理员查询刚才建立的表chained_rows，如果这个表中有相关记录的话，则就说明数据库中存在链化现象。数据库管理员需要采取相应的措施来避免这种情况。如果没有的话最好。

不过在使用这个语句的时候，需要注意几点。一是每次分析完治后，最好把这个表个中的记录删除。因为下次分析的时候，如果表中有记录的话，系统不会自动删除。所以在分析另外一个表的时候，如果也有链化现象，

那么此时相关的记录就会很多，数据库管理员阅读的时候会出现故障。二是这个分析的频率最好频繁一点。当数据库中的记录比较多时或者数据更新比较频繁的情况下，最好能够每隔几天就执行一下这个分析语句，以判断是否有链化现象的存在。等到大量记录或者表格有链化现象的时候，处理起来就会比较困难了。所以对于大部分事务型的数据库系统，数据库管理员要养成一个周期性分析的习惯。对于大部分的数据库优化作业来说，事先追踪远远比时候解决要重要的多。当问题出现后再去解决的话，往往会大费周章，有些即使采取有效的措施，也指能够避免后续的操作不会出现这种情况。要解决以前的记录问题，只有重新导出、导入数据后才能够彻底解决。显然这会增加工作量与数据风险。为此笔者再不厌其烦的强调一次，对于这个链化现象的追踪分析，最好能够每个星期执行一次。特殊情况下，还可以利用任务计划，每天执行一次。尽早发现问题，并采取有效措施来避免这种情况。

二、如何避免链化现象?

当数据库发现有链化现象时，就需要及时调整相关设置，来避免这种情况。造成链化现象的主要原因是由于块的大小设置不合适所造成的。如果一个数据块的大小不能够容纳一条记录，那么就容易造成链化现象。所以如果适当调整数据块的大小，能够在很大程度上避免这个链化现象。在Oracle数据库中，为了有效避免链化现象，可以通过调整参数PCTFREE来实现。这个参数的主要用途就是为更新一个块所保留的空间。有时候系统默认的值往往不能够满足需求。为此需要数据库管理员根据实际需要设置合适的值。值得注意的是，这个值可以根据表来进行设置。为此如果数据库管理员认为某张表的记录可能比较长，需要占用比较大的空间时，则可以针对这张表设置比较大的块。

虽然通过调整PCTFREE参数可以有效避免链化现象。但是有时候表设计不当也是造成这个问题的主要原因之一。如有一张表M_PRODUCT表格，用来存放产品信息。在这张表中，其产品信息主要分为成品与原材料两类。其中原材料这类产品中，在系统中需要记录详细的产品规格信息，而且还需要同时记录中英文内容。所以光这个产品规格，中英文加起来最多的就有3000个左右的字符。而成品信息的话相对来说比较简单。此时这个表中的记录就存在着两极分化的现象。有些记录的容量很大，需要利用多个数据块来进行保存，就发生了链化现象。而有些记录的话，容量不是很大。此时虽然可以通过给这个表设置比较大的数据块来解决这个链化现象;但是同时也会浪费数据空间。因为还有大部分记录的话，根本用不到这么大的块空间。所以在这种情况下，片面调整PCTFREE参数，会降低硬盘空间的利用率。此时，笔者认为最好能够调整数据库表格的设计。如可以将产品规格字段保存在另外一个表格中，然后通过关键字连接到Product表格中。如此的话，在Product表格中，所有记录的的长度都会差不多。此时再根据需要来调整PCTFREE参数，不仅可以有效避免链化现象，而且还同时提高了硬盘空间的利用率。当然，对于新建立的表格，需要适当的提高PCTFREE参数，避免其出现链化现象。不过这个基表的调整，对于已经投入使用的数据库系统来说，调整的动作有点大，会影响用户的正常使用。为此在数据库设计的时候，就需要跟用户充分的沟通。在数据库初始化设计时，就能够预见到这种情况。所以笔者一直强调，数据库优化一定要做在前。

另外，如果数据库中的记录很少更新，如一些决策分析系统或者数据仓库，其只有在刚开始的时候需要大量的导入数据。导入数据后对数据库中的内容基本上不会再更新。此时不需要把PCTFREE参数设置的太大。可以设置比较小的值，能够提高硬盘空间的利用率，让表空间存储更多的记录。可见，PCTFREE 参数的大小没有一个固定的参考标准。其主要根据数据库的用途、表中记录的更新程度、记录的大小等等决定的。如何确定一个合理的PCTFREE参数值，以减少链化现象同时提高表空间的利用率，这也正是数据库优化的难点与挑战所在。

篇4：索引与Null值对于Hints及执行计划的影响数据库

由于B*Tree索引不存储Null值,所以在索引字段允许为空的情况下,某些 Oracle 查询不会使用索引. 很多时候,我们看似可以使用全索引扫描(Full Index Scan)的情况,可能Oracle就会因为Null值的存在而放弃索引. 在此情况下即使使用Hints,Oracle也不会使用索引,其根

由于B*Tree索引不存储Null值,所以在索引字段允许为空的情况下,某些Oracle查询不会使用索引.

很多时候,我们看似可以使用全索引扫描(Full Index Scan)的情况,可能Oracle就会因为Null值的存在而放弃索引.

在此情况下即使使用Hints,Oracle也不会使用索引,其根本原因就是因为Null值的存在.

我们看以下测试.

在username字段为Not Null时,Index Hints可以生效.

SQL>create table t as select username,password from dba_users;

Table created.

SQL>desc t

Name Null? Type

----------------------------------------- -------- ----------------------------

USERNAME NOT NULL VARCHAR2(30)

PASSWORD VARCHAR2(30)

SQL>create index i_t on t(username);

Index created.

SQL>set autotrace trace explain
SQL>select * from t where username='EYGLE';

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT |     |    1 |   34 |    2  (0)| 00:00:01 |
|* 1 | TABLE ACCESS FULL| T   |    1 |   34 |    2  (0)| 00:00:01 |
--------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

1 - filter(”USERNAME“='EYGLE')

Note

-----

- dynamic sampling used for this statement

SQL>set linesize 120
SQL>select /*+ index(t,i_t) */ * from t where username='EYGLE';

Execution Plan

----------------------------------------------------------

Plan hash value: 2928007915

------------------------------------------------------------------------------------
| Id | Operation                  | Name | Rows | Bytes | Cost (%CPU)| Time    |
------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT           |     |    1 |   34 |    2  (0)| 00:00:01 |
|  1 | TABLE ACCESS BY INDEX ROWID| T   |    1 |   34 |    2  (0)| 00:00:01 |
|* 2 |  INDEX RANGE SCAN         | I_T |    1 |      |    1  (0)| 00:00:01 |
------------------------------------------------------------------------------------

Predicate Information (identified by operation id):

---------------------------------------------------

2 - aclearcase/” target=“_blank” >ccess(“USERNAME”='EYGLE')

Note

-----

- dynamic sampling used for this statement

当索引字段允许为Null时,Oracle放弃此索引:

SQL>alter table t modify (username null);

Table altered.

SQL>select /*+ index(t,i_t) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 1601196873

--------------------------------------------------------------------------
| Id | Operation        | Name | Rows | Bytes | Cost (%CPU)| Time    |
--------------------------------------------------------------------------
|  0 | SELECT STATEMENT |     |   27 |  918 |    2  (0)| 00:00:01 |
|  1 | TABLE ACCESS FULL| T   |   27 |  918 |    2  (0)| 00:00:01 |
--------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

当该字段为Not Null时,索引可以被强制使用:

SQL>alter table t modify (username not null);

Table altered.

SQL>select /*+ index(t,i_t) */ * from t;

Execution Plan

----------------------------------------------------------

Plan hash value: 3593393735

------------------------------------------------------------------------------------
| Id | Operation                  | Name | Rows | Bytes | Cost (%CPU)| Time    |
------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT           |     |   27 |  918 |    2  (0)| 00:00:01 |
|  1 | TABLE ACCESS BY INDEX ROWID| T   |   27 |  918 |    2  (0)| 00:00:01 |
|  2 |  INDEX FULL SCAN          | I_T |   27 |      |    1  (0)| 00:00:01 |
------------------------------------------------------------------------------------

Note

-----

- dynamic sampling used for this statement

这就是Null值对于索引及查询的影响.

原文地址：www.eygle.com/archives//02/index_null_hints_explain.html

原文转自：www.ltesting.net

篇5：不要让临时表空间影响Oracle数据库性能数据库教程

在Oracle数据库中进行排序、分组汇总、索引等到作时，会产生很多的临时数据，如有一张员工信息表，数据库中是安装记录建立的时间来保存的。如果用户查询时，使用Order BY排序语句指定按员工编号来排序，那么排序后产生的所有记录就是临时数据。对于这些临时数据，Oracle数据库是如何处理的呢?

通常情况下，Oracle数据库会先将这些临时数据存放到内存的PGA(程序全局区)内。在这个程序全局区中有一个叫做排序区的地方，专门用来存放这些因为排序操作而产生的临时数据。但是这个分区的容量是有限的。当这个分区的大小不足以容纳排序后所产生的记录时，数据库系统就会将临时数据存放到临时表空间中。这就是临时表空间的来历。看起来好像这个临时表空间是个临时工，对于数据库的影响不会有多大。其实大家这是误解这个临时表空间了。在用户进行数据库操作时，排序、分组汇总、索引这些作业是少不了，其会产生大量的临时数据。为此基本上每个数据库都需要用到临时表空间。而如果这个临时表空间设置不当的话，则会给数据库性能带来很大的负面影响。为此管理员在维护这个临时表空间的时候，不能够掉以轻心。要避免因为临时表空间设置不当影响数据库的性能。具体来说，主要需要注意如下几个方面的内容。

一、创建用户时要记得为用户创建临时表空间。

最好在创建用户时为用户指定临时表空间。如可以利用语句default temporary table space语句来为数据库设置默认的临时表空间。不过在Oracle数据库中这个不是强制的。但是笔者强烈建议这么做。因为如果没有为用户指定默认临时表空间的话，那么当这个用户因为排序等操作需要使用到临时表空间的话，数据库系统就会“自作聪明”的利用系统表空间SYSTEM来创建临时段。众所周知，这是一个系统表空间。由于在这个表空间中存放着系统运行相关的数据，一般的建议是用户的数据不能够保存在这个表空间中。那么如果将用户的临时表空间防止在这个系统表空间之内，会产生什么负面影响呢?

由于临时表空间中的数据是临时的。为此数据库系统需要频繁的分配和释放临时段。这些频繁的操作会在系统表空间中产生大量的存储碎片。当这些存储碎片比较多时，就会影响系统读取硬盘的效率，从而影响数据库的性能。其次系统表空间的大小往往是有限制的。此时临时段也来插一脚，就会占用系统表空间的大小。

为此数据库管理员需要注意一点，当没有为用户指定临时表空间时，用户排序等操作仍然需要用到临时段。此时数据库系统就会将临时段放入到系统表空间中。为此就会对数据库的性能产生不利的影响。所以笔者建议各位读者与数据库管理员，在创建用户的时候同时为用户指定一个默认的表空间，以减少临时段对系统表空间的占用。

二、合理设置PGA，减少临时表空间使用的几率。

当排序操作产生临时数据时，数据库并不是马上将其存储在临时表空间中。通常情况下，会先将这些临时数据存储在内存的PGA程序全局区内。只有当这个程序全局区无法容纳全部数据时，数据库系统才会启用临时表空间中的临时段来保存这些数据。但是众所周知，操作系统从内存中读取数据要比从硬盘中读取数据块几千倍。为此比较理想的情况是，这个程序全局区足够的大，可以容纳所有的临时数据。此时数据库系统就永远用不到临时表空间了，

从而可以提高数据库的性能。

但是这毕竟只是一个理想。由于内存大小等多方面的限制，这个PGA程序区的大小往往是有限制的。所以在进行一些大型的排序操作时，这个临时表空间仍然少不了。现在数据库管理员可以做的就是合理设置这个PGA程序全局区的大小，尽量减少临时表空间使用的几率。如在实际工作中，数据库管理员可以根据需要来设置初始化参数SORT_AREA_SIZE参数。这个参数主要控制这个PGA程序全局区内排序区的大小。通常情况下，如果这个数据库系统主要用来查询并且需要大量的排序、分组汇总、索引等操作时，那么可以适当调整这个参数，来扩大PGA分区的大小。相反，如果这个系统主要用于更新操作，或者在这个数据库服务器上还部署由其他的应用程序，那么这个PGA分区就不能够占用太多的内存，以防止对其他应用程序产生不利的影响。所以说，数据库官员不能够一刀切，需要根据实际情况来调整。在必要的情况下，可以增加系统内存来增加PGA分区的大小，从而降低临时表空间的使用几率，以提高数据库的排序、分组汇总等操作的性能。

总之，如果临时段被频繁使用的话，由于内存与硬盘在性能上的差异，从而会降低数据库的性能。为此在平时工作中，数据库管理员还需要监控临时表空间的使用情况，以判断是否需要采取措施来减少临时表空间的使用来提高数据库的查询性能。为了实现这个目的，笔者建议数据库管理员可以查看v0_segment这张动态性能视图。通过这张动态性能视图可以查看系统排序段(临时段的一种)的使用情况。另外通过动态性能视图v0_usage还可以查询使用排序段的用户与会话信息。从而为数据库管理员优化数据库性能提供数据上的支持。对于这个排序段，笔者还要说明一点。对于排序段来说，同一个例程的所有SQL语句(如果需要排序操作的话)都将共享同一个排序段。并且排序段在第一次需要用到时被创建。排序完成后这个排序段不会被释放，只有在这个历程关闭后排序段才会被释放。为此以上两张视图要综合起来分析，才能够得到数据库管理员想要的信息。

三、要为临时表空间保留足够的硬盘空间。

其他表空间对应的数据文件，在其创建时就会被完全分配和初始化，即在其创建时就会被分配存储空间。但是临时表空间对应的临时文件则不同。如在Linux操作系统中，临时表空间创建时系统是不会分配和初始化临时文件的。也就是说，不会为临时文件分配存储空间。只有临时数据出现需要用到临时文件的时候，系统才会在硬盘上分配一块地方用来保存临时文件。此时就可能会产生一个问题，即当需要用到临时文件系统为其分配空间的时候，才会先系统分区中没有足够的存储空间了。此时就会产生一些难以预料的后果。

为此对于这些临时文件，数据库管理员最好能够预先为其保留足够的空间。如在Linux操作系统中，可以将其防止在一个独立的分区内，不允许其他应用程序使用。如此的话，就不用担心临时文件没有地方存储了。另外由于临时表空间主要用来存放一些排序用的临时文件。为此如果能够将这个临时表空间存放在性能比较好的分区中，还可以提高数据库系统读取临时表空间中数据的速度。另外由于系统需要频繁分配临时表空间中的数据，为此临时表空间所在的分区会出现比较多的碎片。此时如果将临时表空间存放在一个独立的分区内，那么数据库管理员就可以单独对这个分区进行碎片整理，从而提高这个分区的性能。所以无论出于什么原因，将临时表空间防止在一个独立的分区内，是一个不错的想法。不仅可以保证临时文件有存储的空间，而且还可以提高数据库的性能。

对于临时表空间最后需要说明的是，默认情况下这个临时表空间对各个用户都是共享的。也就是说每个连接到数据库的用户都可以使用默认的临时表空间。数据库管理员可以为其指定其他的临时表空间。一般来说，只需要一个临时表空间即可

【disablelogging对于性能的影响数据库】相关文章：

1.SQL Server数据库性能优化

2.SQL Server数据库性能优化技巧

3.索引与Null值对于Hints及执行计划的影响数据库

4.家庭教育对于孩子心理健康的影响

5.面向程序员的数据库访问性能优化法则

6.掺杂ZnO对SnO2电极烧结性能的影响

7.海棠花的养殖方法和对于家居环境的影响介绍

8.防老剂对HTPB-IPDI高燃速推进剂性能影响研究(Ⅱ)

9.对于人生

10.对于近义词