`

db2学习笔记(二)

    博客分类:
  • db2
阅读更多

表空间方面:
1.创建数据库的时候,默认会有3个页大小为4k的系统管理表空间(syscatspace,系统临时表空间,用户

数据表空间)。先把系统临时表空间和用户数据表空间删除掉,自己另外建。建的时候注意要多加几个容

器(这个时候根据你的磁盘决定),而且容器的大小最好一样大(有多个容器后可以使用预 取功能,表

空间只有一个容器没法预取)。多个容器主要是考虑I/O问题。这个也是数据库性能很重要的一个方面(

其他2个方面是内存和cpu)。几乎在所有情况下,SYSCATSPACE都不需要做进一步的优化。但如果把其容

器展开到其他几个磁盘上,性能上可能会有少许的提升。
2.对于系统临时表空间和系统编目目表空间,应该使用sms。因为他允许表空间动态的增长和收缩。如果

有大量临时表要刷新到磁盘上(或者没有足够的排序空间,或者是显式的创建临时表空间),则 DMS 会

更有效一些。当在db2 8以前的版本使用 SMS 时,应该运行实用程序 'db2empfa',这个实用程序将支持

多页文件分配,从而一次一个区段地增长表空间,而不是一次一页地增长表空间。
3.对于除了上面提到的所有其他的表空间,应该使用 Database Managed Storage(DMS)。DMS 允许一个表

跨越多个表空间(索引、用户数据和 LOB),这样就减少了在预取和更新操作时索引、用户和 LOB 数据

之间的争用,从而缩短了数据访问的时间。通过使用 DMS raw 甚至还可以挤出额外的 5-10% 的性能提升

。 数据和索引要使用不同的表空间。
4.创建表空间的时候有2个选项:extent和prefetch。Extent Size 指定在跳到下一个容器之前,可以写

入到一个容器中的 PAGESIZE 页面的数量。其中extent大小以后是不可以改的,而prefetch大小是可以改

变的。
下面的经验法则是建立在表空间中每个表的平均大小的基础上的:
 如果小于 25 MB,Extent Size 为 8
 如果介于 25 到 250 MB 之间,则 Extent Size 为 16
 如果介于 250 MB 到 2 GB 之间,则 Extent Size 为 32
 如果大于 2 GB,则 Extent Size 为 64
====上面的参考是ibm提供的数据,我觉得这些数据都是ibm经过很多测试得出的结果,所以我建议对ibm

提供的这方面数据大家还是注重考虑下(这个也是我平时经验得出的。有些时候我修改了ibm一些配置参

数后,cpu会100%,所以除了一般的数据,修改数据库的值我都会认真考虑下的)。
5.有时候必须使用较大的页面大小,以回避某些数据库管理器的限制。一个表空间最多只能有16384个页

,所以不同页大小的表空间大小的是有不同的限制的。

6.系统的临时表空间对数据库性能影响很大,当由管理的物理内存不能满足数据库操作的需要时,DB2便会把临时数据写到磁盘上,这时便用到了系统临时表空间,并且这种情况会经常发生。 (排序和重组)
7。.最后就是对表空间页大小的设置了,这个我也没什么经验。等明白点的在写吧(以后肯定会补的)。

   补充:a.对于行的长度较小的,或者访问基本是随机的。就可以使用4k的页。而对于行长度叫大的表,应该选择较大的页表空间(这个时候选择较小的页,可能会引起数据库潜在的性能问题:更多的io操作)。

8.这两种类型的表空间上,数据的放置也会有所不同。例如,考虑高效表扫描的这样的一个需要:重要的是扩展数据块中的页在物理上是连续的。对于 SMS,操作系统的文件系统决定了每个逻辑文件页的物理放置位置。根据文件系统上其它活动的级别以及用来确定放置位置的算法的不同,这些页可能连续分配,也可能不连续分配。但是,对于 DMS,因为数据库管理器直接与磁盘打交道,所以它可以确保这些页在物理上是连续的。

9.一般而言,在物理设备上设计如何放置表空间和容器时,目标是使 I/O 并行性和缓冲区利用率达到最优。要实现这个目标,应当全面了解数据库设计和应用程序。只有这样您才能确定类似于下面这样的问题:将两张表分隔到不同的设备会不会产生并行 I/O,或者,是否应当在单独的表空间中创建表以便可以对它进行完全缓冲

 

===========================

 

1.       对于优化器决定那个是外表,哪个是内表的一些规则:

  1. 表越小,越有可能被选为外表。这有助于减少必须再次访问内表的次数。<o:p></o:p>
  2. 如果选择谓词可以应用到某个表,则该表更适合于被选作外表,因为在访问内表时只会用那些符合这些谓词(应用于该外表的)的行。
  3. 如果可能对其中某个表做索引查找,则该表很适合于作为内表。如果一个表没有索引,则最好不要将其作为内表,因为每扫描外表中的一行,就要扫描一遍整个内表。
  4. 在连接操作中,重复元素最少的表倾向于被选作外表。(???
  5. 补:最终性能一般取决于确切的符合条件的行数以及其它因素(譬如,数据库的设计、数据库的组织、统计信息的精确性、硬件类型和 DB2 环境的设置等)。

2 .  DB2信息中心下载地址:http://www.ibm.com/developerworks/cn/db2/v9/index_download.html<o:p></o:p>

3. 关于sql重写:我们写的sql可能效率不是很高,所以数据库在执行我们sql的时候,会把我们的sql进行重写,一个目的是为了使数据库能够更好的识别,另外一个便是进行各种优化. 可以下列三种主要方式中的任何一种重写查询<o:p></o:p>

   A. 操作合并 : <o:p></o:p>

       (1). 示例 视图合并:  使用视图的 SELECT 语句可限制表的连接顺序并可引入表的冗余连接。如果在查询重写期间合并视图,则可撤销这些限制。===(这个告诉我们:我们在写sql的时候,尽量不要使用视图连接视图,这样会降低效率,而且数据库有时候也会判断不准确,限制表的连接类型,从而提高成本。)<o:p></o:p>

   (2). 示例 子查询至连接的变换: 如果某个 SELECT 语句包含子查询,则可以限制表的顺序处理的选择。====(这个告诉我们:在写子查询的时候,要尽量考虑是不是可以不用子查询,从而不用限制表的顺序处理)<o:p></o:p>

  3. 消除冗余连接 : 在查询重写期间,可除去冗余连接来简化 SELECT 语句。<o:p></o:p>

   (4). 示例 共享聚集 : 当查询使用不同的函数时,重写可减少需要执行的计算数。(这个不是很明白)<o:p></o:p>

4.获取db2的某个数据库的锁信息的命令 db2pd –db   dbname –locks –file fielname .但这个命令显示的结果怎么分析,还不是很明白,希望以后能明白<o:p></o:p>

5. 使用DB2 8版本前,要运行’db2empfa’, 这个实用程序将支持多页文件分配,从而一次一个区段地增长表空间,而不是一次一页地增长表空间。<o:p></o:p>

<o:p> </o:p>

6.检查数据库备份文件是否可用的命令 :db2ckbkp  后面跟备份文件路径<o:p></o:p>

<o:p> </o:p>

7.关于异步页清除程序的数目 配置参数:num_iocleaners.<o:p></o:p>

  Bufferpool 中的数据有2个方法可以被移除:一个就是这里的异步页清除程序,另外一个就是代理进程的预期工作时。明显异步页清除可以明显改善i/o,从而改善性能。关于      的设置值:<o:p></o:p>

1.打开bufferpool快照,程序运行一段时间后,获取快照,看   缓冲池数据写入  异步池数据页写入,缓冲池索引写入  和异步池索引页写入 参数值,(代理进程的预期写磁盘的数据量为   缓冲池数据写入 -  异步池数据页写入)<o:p></o:p>

如果同时满足下面两个条件,则可以减小该参数: <o:p></o:p>

o    pool_data_writes 大约等于 pool_async_data_writes <o:p></o:p>

o    pool_index_writes 大约等于 pool_async_index_writes <o:p></o:p>

·         如果下列任何一种情况为真,则应增大该参数: <o:p></o:p>

o    pool_data_writes pool_async_data_writes 大很多 <o:p></o:p>

o    pool_index_writes pool_async_index_writes 大很多<o:p></o:p>

8. 异步 I/O 服务器和页面清洗器(这个很重要)<o:p></o:p>

DB2 UDB 鼓励缓冲池与磁盘之间页面读写的异步 I/O 访问,以便获得最优性能。 <o:p></o:p>

I/O 服务器将数据页异步地从磁盘读入参与应用程序需求的缓冲池中:这称作预取(prefetching。预取可以提高数据库的性能,因为当代理访问这些页面时,将在缓冲池中找到它们,从而减少了应用程序等待页面从磁盘读入缓冲池的时间。<o:p></o:p>

另一方面,数据库代理需要缓冲池中的空间之前,页面清洗器将已修改的页面从缓冲池写入磁盘。因此,数据库代理不必等待写出修改的页面,就可以使用缓冲池中的空间。这将提高数据库的整体性能。页面清洗器可以通过多种理由触发,例如,当达到已修改页面的阈值时。 <o:p></o:p>

配置
用于数据库的 I/O 服务器(预取器)的数目可以使用 NUM_IOSERVERS 数据库配置参数进行配置。为了充分利用系统中的所有 I/O 设备,使用较好的值通常是比数据库所驻留的物理设备的数目多一两个。最好配置附加的 I/O 服务器,因为每个 I/O 服务器相关的开销非常小,而未使用的 I/O 服务器仍然将保持空闲。<o:p></o:p>

NUM_IOCLEANERS 数据库配置参数允许您为数据库指定异步页面清洗器的数目。在为该参数设置值时,要考虑下列因素: <o:p></o:p>

  • 应用程序类型
    如果是一个不具有更新而仅仅查询的数据库,就将该参数设置为 0。如果查询工作负载导致创建许多 TEMP 表(您可以通过使用解释实用程序来确定)时除外。如果事务是对数据库运行的,那么就将该参数设置成 1 到用于该数据库的物理存储设备数目之间的值。 <o:p></o:p>
  • 工作负载
    具有较高事务更新率的环境可能需要配置更多页面清洗器。 <o:p></o:p>
  • 缓冲池大小
    具有大型缓冲池的环境也可能需要配置更多页面清洗器。 <o:p></o:p>

还请记住,配置太多页面清洗器可能会损害数据库服务器上的运行队列,并导致极大的性能下降。因此,根据经验法则,您可以考虑将页面清洗器的数目设置为数据库服务器上 CPU 的数目。 <o:p></o:p>

已修改页面的阈值参数(CHNGPGS_THRESH)决定异步页面清洗器应启动时已修改的页面的百分比。 <o:p></o:p>

监控
因为异步页面清洗器和 I/O 服务器的活动与缓冲池活动是如此紧密联系,所以您可以再次利用缓冲池快照来测量页面清洗器和预取器的有效性。 <o:p></o:p>

这此,缓冲池快照的重要元素将重点放在了下面: <o:p></o:p>


Buffer pool data logical reads = 2700145
Buffer pool data writes = 0
Buffer pool index logical reads = 95
Asynchronous pool data page reads = 85
Asynchronous pool data page writes = 0
Buffer pool index writes = 0
Asynchronous pool index page reads = 0
Asynchronous pool index page writes = 0
<o:p></o:p>

预取活动可以通过异步和同步的读 I/O 来确认。异步读取比率按照下列公式计算: The prefetching activity can be validated by the amount of asynchronous versus synchronous read I/O. The asynchronous read ratio is calculated as follows: <o:p></o:p>

((异步池数据页读 + 异步池索引页读) / (缓冲池数据逻辑读 + 缓冲池索引逻辑读)) * 100% <o:p></o:p>

异步读取比率值较小可能是由多种原因导致的,例如: <o:p></o:p>

  • 工作负载读写单行,因此它无法利用预取。 <o:p></o:p>
  • 为数据库配置的预取器太少。 <o:p></o:p>
  • 数据库中的表空间仅仅配置了一个容器,以致无法进行预取。 <o:p></o:p>

异步页面清洗器的有效性是由异步数据和索引页的写比率进行测量的。如果下列两个条件都成立,那么就可以减少异步页面清洗器的数目(NUM_IOCLEANERS): <o:p></o:p>

  • 缓冲池数据写约等于异步池数据页写 <o:p></o:p>
  • 缓冲池索引写约等于异步池索引页写 <o:p></o:p>

如果下列条件中有一个成立,就应增加该参数:<o:p></o:p>

  • 缓冲池数据写远远大于异步池数据页写 <o:p></o:p>
  • 缓冲池索引写远远大于异步池索引页写 <o:p></o:p>

示例 <o:p></o:p>

首先,验证 NUM_IOSERVERS NUM_IOCLEANERS 参数的当前设置:

分享到:
评论

相关推荐

Global site tag (gtag.js) - Google Analytics