简介

由于使用了越来越多的安全性设备和应用程序，在企业级单位中会产生大量与安全性相关的信息。如果没有完善设计的安全性事件收集和分析架构，存储、检索和理解这样巨大的信息量是非常困难的。

IBM Tivoli Security Operations Manager (TSOM) 是一个高级安全性信息和事件管理（SIEM）软件平台，它能够提高企业安全性操作的有效性、效率和可见性。您可以使用它来管理整个企业中来自物理设备和应用程序的与安全性相关的信息和事件，从而有助于满足企业安全性事件收集和分析架构的需求。

IBM TSOM 是从 IBM Tivoli Risk Manager and Netcool® for Security Management 演化而来的。它是专门通过使用最新的前缘分析和相关性分析特性来处理快速增长的企业安全性架构需求，而这些特性是以前的产品所不具备的。IBM TSOM 不仅使安全性管理员和分析人员能够实时地解析和管理安全性事件，还有助于执行人员理解安全性，以及遵守他们公司的规范。

IBM TSOM 的性能是直接与其后台数据库紧密相关的，如 IBM DB2 for Linux, UNIX, and Windows。IBM TSOM 是依靠底层的数据库管理系统来实现诸如相关性分析、配置、历史搜索和生成报表等功能。所有事件都是实时地写入到数据库，以及从数据库读取的。同时 IBM TSOM 和 DB2 之间会持续交换大量的数据。例如，在一个生产环境中，几周时间里可能就会有 500 GB 到 1 TB 的数据写入数据库。因此，为了实现最佳性能的高级 SIEM 解决方案，您应该考虑一些优化特定环境数据库的具体 DB2 参数。

在开始优化各个 IBM DB2 参数实现最佳性能的 IBM TSOM 的过程之前，您应该先理解创建 DB2 环境所需要的步骤。

创建 IBM DB2 环境

为了修改 DB2 参数，操作系统的登录上下文必须是 DB2 实例的拥有者。下面的例子将介绍如何切换到一个名为 tsom 的 DB2 实例拥有者登录上下文。

在 Linux 或 UNIX 操作系统上，输入以下命令：

su - tsom

在 Windows 系统上，输入以下命令：

db2cmd
set DB2INSTANCE=tsom

DB2 参数可能属于数据库管理器层、数据库层或者注册表层，同时可以进行以下方式修改。

如果是一个数据库管理器层的配置参数：

  db2 update dbm cfg using <parm_name> <parm_value> 

如果是一个数据库层配置参数：

  db2 update db cfg for <database name> using <parm_name> <parm_value> 

如果是一个 db2 注册表参数：

  db2set <parm_name>=<parm_value> 

—— 其中 <parm_name> 是参数名，而 <parm_value> 是新设置的值。

为了使修改生效，您应该在修改 DB2 注册表参数、静态数据库层配置参数或者静态数据库管理顺层配置参数之后重要启动数据库或数据库管理器。

重新启动数据库：

db2 terminate 
db2 deactivate db <database name>
db2 connect to db <database name>

重新启动数据库管理器：

db2 force applications all
db2stop force
db2start

IBM DB2 服务器可以安装在 32 位或者 64 位硬件上。然而，您应该使用 64 位 IBM DB2 作为 IBM TSOM 数据库，因为 64 位数据库比 32 位数据库能够更好地处理内存。

当您完成 DB2 环境的创建之后，您就能够继续后续的优化操作了。下面的章节将介绍您在配置 IBM DB2 以实现最优的 IBM TSOM 所需要的各个方面性能优化操作。

设计 DB2 表空间

每一个 DB2 数据库都至少包含一个分类表空间，一个或多个用户空间，以及一个或多个临时表空间。表空间是包含最终用户实际数据的逻辑实体。表空间可以由一个或多个容器组成，这些容器可是操作系统的一个文件或一个目录。表空间容器是 IBM DB2 数据库的物理存储。

为了在不同缓冲池中隔离对象，您可以在同一个数据库中创建一个以上的表空间，并给每一个表空间关联不同的缓冲池。

表空间有三种。

系统管理的空间（System-managed space，SMS）

操作系统文件系统管理器负责分配和管理这个空间。在 DB2 9 以前的版本中，如果不使用任何参数来创建一个数据库或表空间，那么所有表空间都会作为 SMS 对象创建。

数据库管理的空间（Database-managed space，DMS）

数据库管理器负责控制这个存储空间。这个表空间是最适合数据库管理器需求的一种特殊用途文件系统的一个实现。

使用 DMS 实现的自动存储

自动存储实际上并不是一种表空间，而是另一种处理 DMS 存储的方法。DMS 容器需要更多的维护，而自动存储是在 DB2 V8.2.2 引入的，它是一种简化空间管理的方法。通过自动存储，DB2 能够创建一个遍布为自动存储声明的整个路径的容器。多个存储单元将通过实现 I/O 并行而提高性能。

默认情况下，不同的 IBM TSOM 表是在默认表空间创建的，所以您应该使用另一个表空间来存储事件数据和事件表索引。通过分割事件数据、索引和不同存储单元的日志文件，您就可以利用并行 I/O 来提高 IBM TSOM 的性能。

强烈建议您使用自动存储来管理表空间。清单 1 显示了用于创建存储表空间的命令。

				
create regular table space data_ts pagesize 32 k managed by automatic storage 
extentsize 32 overhead 10.5 prefetchsize 32 transferrate 0.14 bufferpool 
data_bp dropped table recovery off no file system caching;

create regular table space index_ts pagesize 32 k managed automatic storage 
extentsize 32 overhead 10.5 prefetchsize 32 transferrate 0.14 bufferpool 
index_bp dropped table recovery off no file system caching;

为了在这些表空间中创建事件数据表，您需要注释 itsom_tables_db2.sql 脚本中的以下代码行来重新创建事件表，这个脚本位于 Central Management Server (CMS) 的 {TSOM Directory}/schema/。

--IN DATA_TS INDEX IN INDEX_TS

回页首

优化 IBM DB2 数据库缓冲池

由于数据位于系统的主内存中，所以缓冲池能够减少磁盘读取时间，从而提高了数据库性能。因为 DB2 缓冲池是系统主内存的一部分，DB2 数据库管理器在它读取或写入磁盘介质时将它分配给缓存表和索引数据。每一个 DB2 数据库都必须至少拥有一个缓冲池。

当您在 UNIX 平台上创建一个 DB2 数据库时，一个默认的缓冲池 IBMDEFAULTBP 会被创建，它具有 1000 个页大小为 4k 的页。而在其他平台上，缓冲池大小为 250 个页大小为 4K 的页。当您配置新的缓冲池时，一定要理解它对系统可用内存的影响。

您可以使用以下命令来创建缓冲池：

connect to <database name>;
create bufferpool data_bp immediate size 250 pagesize 8K; 
create bufferpool index_bp immediate size 250 pagesize 8K;

您可以使用以下命令在创建后修改缓冲池大小：

alter bufferpool bufferpool_name <size new_size_in_32768_byte_pages>
terminate 

虽然优化 DB2 缓冲池是有些难度的，但是您能够显著提升性能。当您设计缓冲池时，您应该考虑数据库的内存需求。例如，查看主机的可用内存，以及同一台主机上与 DB2 同时运行的其他应用程序所需要的内存。此外，您不应该在安装了 DB2 服务器的同一个主机上运行其他应用程序。如果缓存更多的数据库用户数据，那么性能就会得到提升。然而，这并不意味着您总是需要创建较大的缓冲池。如果缓冲池大小过大，那么内存使用会超过可用的物理内存，从而导致操作花费更多时间对内存进行分页。

您可以使用 IBM DB2 服务器的 Self Tuning Memory Manager (STMM) 来测量和分析 DB2 数据库内存的消耗情况，同时动态地分配内存以优化负载性能。您也可以使用 STMM 来管理 DB2 内存需求和使用，这样它才能够平衡相同或不同实例的操作系统、其他应用程序和其他数据库的需求。您可以使用以下命令来创建一个由 STMM 管理内存的新缓冲池：

create bufferpool <pool_name> immediate size 250 automatic pagesize 32K; 

数据库的所有表都是在 IBM TSOM 默认安装的默认表空间 USERSPACE1 和缓冲池 IBMDEFAULTBP 中创建的。由于 EVENT_DATA、 EVENT_DATA_SECURITY_DOMAIN_MAP 和 EVENT_DATA_EVENT_CLASS_MAP 事件表具有不变的特点，所以您应该为它们创建专用的表空间和 STMM 管理的缓冲池。下面是一个示例的缓冲池定义，它为事件和事件表索引定义不同的缓冲池：

create bufferpool data_bp immediate size 2500 automatic pagesize 32K; 
create bufferpool index_bp immediate size 625 automatic pagesize 32K;

您可以看到页大小被设置为 32k 而不是默认的 4k，这可以改进事件插入过程的性能，结果分配的内存为 2500*32k + 625*32k = 100 MB。

回页首

实现表分区特性

DB2 V9 引入了一个表分区特性，它能够增加一个表的可能大小，同时能够显著减少管理大型数据库所需要的维护。您可以使用表分区将数据存储在同一个数据库表的不同分区中。您可以使用包含来自一定范围值的字段来创建分区，如使用日期条件，将分区分成 Jan、Feb、March 等等；或者分成 1st_Quarter、2nd_Quarter 等等。分区数的理论限制值为 32,000，而表和表空间针对 32 k 页面所支持的最大值是 16 TB。尽管表分区就像是一个单独的表，但是一个分区理论上最大可以达到 16 TB。

IBM TSOM 使用范围分区实现事件表，所以您可以分离一个分区，将分离的分区保存在一个外部存储上，或者删除所分离的分区。

如果您向事件表发起的大部分查询都位于事件规范化时间（范围划分字段）的一个 24 小时窗口中，那么您可以使用日常分区改进一个事件表中的非索引字段的查询性能。您可以很容易使用 DB2 alter table 命令来附加和分离分区，从而将数据从一个表（生产表）移动到同一个数据库的另一个表（历史表）中。

配置 DB2 事务日志

任何关系数据库的基本操作都包括 CREATE、INSERT、DELETE、UPDATE、DROP 等等。DB2 在事务日志中记录了数据库对象的所有操作或修改。所有的修改在 COMMIT 时，被写入数据库之前都首先会被写入到一个日志文件中，所以在出现如电源故障等意外事故时，这些日志文件可用于将数据库改回一致的状态。

日志缓冲区

在日志记录被写入日志文件之前，它们首先会被写到缓冲区。定义日志缓冲区大小的数据库配置参数为 LOGBUFSZ。这部分内存是从 database heap 分配的，其大小是由数据库配置参数 DBHEAP 控制的。

这个日志记录会在出现以下情况时被写到磁盘中：

• 日志缓冲区已满。
• 出现其他一些内部数据库管理器事件。

缓冲日志记录可以实现更高效的日志文件 I/O，因为日志记录写入磁盘的频率会下降，而每次 I/O 会有更多的日志记录被写入日志文件。

使用 IBM TSOM 最适合采用大小为 4096 的 LOGBUFSZ。您可以使用以下命令修改数据库堆的大小和日志缓冲大小：

update db cfg for <database name> using dbheap 50000
update db cfg for <database name> using logbufsz 4096

主日志文件与次日志文件

日志文件有两种：

• PRIMARY
• SECONDARY

主日志文件建立了一个固定大小的存储空间，这是分配给恢复日志文件的。这些文件是在第一次连接数据库时预先分配好的。数据库配置参数 LOGPRIMARY 决定了主日志文件的数量。而这些日志文件的大小是由数据库配置参数 LOGFILSIZ 决定的。

当主日志文件用完时，次日志文件会一次按需分配完毕的，最大可分配数据库配置参数 LOGSECOND 所指定的值。数据库配置参数 LOGFILSIZ 则指定了次日志文件的大小。

说明：UNIX 版本的 DB2 的 LOGFILSIZ 默认值为 1000 个页。对于 Windows，这个值为 250 个页。而页大小都是 4 KB。

主日志文件（LOGPRIMARY）的默认数量是定义为 3，而次日志文件（LOGSECOND）则为 2。而空闲的磁盘空间必须大于或等于以下公式所定义的大小：(LOGFILSIZ * 4096 * (LOGPRIMARY + LOGSECOND) / 1024) KB。

以下的 DB2 命令显示输出包括了这些参数的当前设置，其中 tsom 是 IBM TSOM 所使用的数据库名：

get database configuration for tsom |
egrep 'LOGFILSIZ|LOGPRIMARY|LOGSECOND|NEWLOGPATH|Path to log files' 

LOGFILSZ 的最优值为 20000。您可以使用以下命令来修改日志文件大小参数：

update db cfg for <database name> using logfilsiz 20000

回页首

优化内存堆和 DB2 注册表变量

应用程序堆大小

应用程序堆大小参数定义了数据库管理器的一个特定代理或子代理所能使用的私有内存页数。计算的单位为 4k 页。

db2 update db cfg for <database name> using applheapsz 2048

您可以在一开始启动 2048 的页。然而，如果您遇到任何与 applheapsz 有关的问题，您可以在之后在不影响 IBM TSOM 工作的情况下动态地修改它。

CHNGPGS_THRESH

CHNGPGS_THRESH 的默认值是 60%，这表示缓冲池中有 60% 的页是修改过的（即，包含了数据），NUM_IO_CLEANERS 这时就会开始异步地将修改的页写入到磁盘中。

您可以通过以下命令将 CHNGPGS_THRESH 减少到 30（25 至 40 范围内），从而提高事件插入性能：

db2 update db cfg for <database name> using CHNGPGS_THRESH 30

DB2_SKIPINSERTED

为了实现更好的响应时间，您可以使用 db2set 命令设置 DB2_SKIPINSERTED=ON，忽略插入但未提交的记录。否则 DB2 会一直等待这些记录直到完成提交操作，这会降低读取的速度。您可以使用以下命令将 DB2_SKIPINSERTED 设置为 ON：

db2set DB2_SKIPINSERTED=ON

说明：某些数据库参数的错误设置可能会导致数据库错误。如果您怀疑出现了错误配置，您应该检查 diagpath 所指参数的目录中的 db2diag.log 文件，查看是否有与操作系统相关的错误消息。diagpath 参数是数据库管理器层的配置参数，它指向 DB2 诊断信息的完整路径。

回页首

通过创建索引提高 IBM TSOM 历史数据查询性能

索引是一个指向基础表的有序指针集。索引能够避免全表扫描，从而能够提高查询性能。然而，索引的维护负载可能会对 INSERT、UPDATE 和 DELETE 语句产生负面影响。

默认情况下，EVENT_DATA 表的以下字段定义了索引：sensor_id_fk、event_type_id_fk、source_ip、destination_ip、destination_host_id_fk 和 source_host_id_fk。

如果您的应用程序频繁地在 WHERE 子句中查询 EVENT_DATA 表的其他字段，那么您可以考虑创建其他字段的索引。

为提高性能，您可以在以下两个表中创建额外索引：

• EVENT_DATA_SECURITY_DOMAIN_MAP
• EVENT_DATA

在这些表上创建额外的索引的语法：

CREATE INDEX DB2INST1.EDSDM_NORM ON DB2INST1.EVENT_DATA_SECURITY_DOMAIN_MAP 
("NORMALIZATION_TIME" ASC, "SECURITY_DOMAIN_ID_FK" ASC, "EVENT_DATA_ID_FK" ASC) 
ALLOW REVERSE SCANS ;

RUNSTATS ON TABLE DB2INST1.EVENT_DATA_SECURITY_DOMAIN_MAP FOR INDEX DB2INST1.EDSDM_NORM;

CREATE INDEX DB2INST1.ED_NORM ON DB2INST1.EVENT_DATA ("NORMALIZATION_TIME" ASC, 
"EVENT_DATA_ID" ASC) ALLOW REVERSE SCANS ;

RUNSTATS ON TABLE DB2INST1.EVENT_DATA FOR INDEX DB2INST1.ED_NORM ;

COMMIT WORK ;

使用以下命令查看一个特定表已有的索引：

connect to tsom 
describe indexes for table <table name> show detail 

使用以下命令创建新的索引：

create index <index name> on <table name>
(<column_names separated by commas and ordered by>);

您可以使用 IN 子句在用户数据所在的表空间上创建一个索引，或者在其他表空间上创建索引。您应该在单独的一个表空间上创建索引，这样如果索引表空间出现问题，您可以直接删除该表空间，然后重要创建相同的索引。

您在创建新索引之后运行 reorg 和 runstats 命令，如下所示：

reorg indexes all for table <Table name>
runstats on table <schema name>.<table name> and detailed indexes all

DB2 Design Advisor 是一个能够自动推荐索引的工具。

Design Advisor 能够帮助您：

• 发现一个问题查询的最优索引
• 发现一组受资源限制影响、选择性应用的查询（工作负载）的最优索引
• 在不创建索引的情况下为一个工作负载测试索引

您可以从 DB2 Control Center 启动 Design Advisor，或者使用 db2advis 命令启动。

db2advis 输出也实现了相同的创建推荐索引的语法。

回页首

DB2 服务器磁盘空间需求

当 IBM TSOM 配置使用支持 1000 EPS（每秒事件数）环境的 IBM DB2 时，大部分的磁盘空间会被事件消耗。下面的等式显示对于 1KB 事件（varchar 域会引起各位置的不同）而言，这个空间按三个月的保存期计算会达到每秒 1000 个事件：

1000(EPS)*60(Seconds)*60(Minutes)*24(Hours per day)*90(Number of days)*1 KB
                (Approximate size of every event) = 7,776,000,000 KB =~ 7.7 TB

DB2 服务器磁盘写入速率

插入过程是数据库中实质上的 I/O 开销。一般即使旧的较慢的硬件平台上，CPU、内存和 BUS 组件都足以支撑插入操作。而只有磁盘写入速率才会造成瓶颈。在这种情况下，您可以通过连接启用了写缓存的外部存储设备来提高性能。

发现事件插入过程中的 I/O 瓶颈

处理器时间由 4 个时间模式组成：系统时间、用户时间、I/O 等待时间和空闲时间。在部署了 DB2 服务器的主机上，您应该监控等待时间。当一个过程等待一个块设备数据请求完成时，它会增加 I/O 等待时间，而所有空闲都会变成等待时间。如果您注意到空闲时间为 0，那么您应该检查系统是否存在吞吐问题。

要保证磁盘写入速度满足预期 EPS 的要求。例如，当写入速度为 1000 事件/秒时，磁盘写入速度大约为 1 MB/秒。

测试后台数据库的 CMS 查询性能

您可以打开 OJB 日志，查看后台数据库的 CMS 正在执行的查询。要打开 OJB 日志，您应该使用以下步骤：

1. 编辑 {tsom_home}/conf/db/OJB-logging.properties 文件，删除从 # Logger for jdbc access querying and object materialization 开始的那部分注释。

   # Logger for jdbc access querying and object materialization, useful # for debugging JDBC related problems org.apache.ojb.broker.accesslayer.JdbcAccessImpl.LogLevel=DEBUG org.apache.ojb.broker.accesslayer.RsIterator.LogLevel=WARN org.apache.ojb.broker.accesslayer.StatementsForClassImpl.LogLevel=DEBUG org.apache.ojb.broker.accesslayer.sql.SqlGeneratorDefaultImpl.LogLevel=DEBUG org.apache.ojb.broker.core.QueryReferenceBroker.LogLevel=ERROR

   
   
2. 停止 CMS，等待几分钟，然后重新启动 CMS。您将会看到上面的日志输出被写到 {tsom_home}/logs/server.log 文件中。
3. 为了测试查询的性能，您需要输入以下命令：

   db2batch -d dbname -f input.txt -cli -r output.txt

   
   其中，dbname 指定了执行查询的数据库，input.txt 指定了 SQL 查询的输入文件，cli 指定了在 CLI 模式下运行，output.txt 指定了 db2batch 命令结果导向的文件。
4. db2batch 工具以算术和几何图形的格式对性能进行了概括。对于语法和选项，请在命令行中输入 db2batch -h 进行查看。说明：SQL 查询一般执行时间很稍长一些。

回页首

结束语

您已经了解了您可用于优化 IBM DB2 的各种步骤。通过使用本文所述的过程，您可以显著地提高使用 IBM DB2 作为后台数据库的 IBM TSOM 的性能，以及减少此类环境中通常遇到的停机时间。建议您测试本文所介绍的过程以查询它们能实现的效果。

参考资料

学习

• 从 IBM DB2 for Linux, UNIX, and Windows Information Center 了解更多关于 DB2 优化的信息。
  
  
• 从 Tivoli Security Operations Manager Information Center 了解更多关于 IBM TSOM 的信息。
  
  
• 从 IBM TSOM Support Portal 获取 Tivoli 支持资源。
  
  
• IBM 红皮书：Deployment Guide Series - IBM Tivoli Security Operations Manager ：了解规划安全性事件和信息管理项目所需要的信息。
  
  
• 从 developerWorks 的 DB2 for Linux, UNIX, and Windows 专区 获取提高您的 DB2 技能的资源。
  
  

获得产品和技术

• 下载 DB2 9.7 for Linux, UNIX, and Windows 的免费试用版。
  
  

讨论

• 参与论坛讨论。
  
  
• 参与 developerWorks 博客 并加入 developerWorks 中文社区。
  
  

作者简介

Boudhayan Chakrabarty 是 IBM 印度软件实验室的 IBM Tivoli 安全性团队成员之一，该团队专注于安全遵从性产品研发，如 IBM Tivoli Security Operations Manager (TSOM)、IBM Tivoli Compliance Insight Manager (TCIM) 和 IBM Tivoli Security Information and Event Manager (TSIEM)。他拥有印度布巴内斯瓦尔工学院的的计算机科学学位。

Yogesh Gawali 是普纳 IBM India Software Lab 的一位 DB2 高级技术支持分析师，他致力于为全世界的 IBM DB2 客户提供技术支持。他在客户问题诊断和解决方面有极为丰富的经验。他拥有普纳大学计算机工程学士学位。

为本文评分

评论

回页首

内容

• 简介
• 创建 IBM DB2 环境
• 设计 DB2 表空间
• 优化 IBM DB2 数据库缓冲池
• 实现表分区特性
• 配置 DB2 事务日志
• 优化内存堆和 DB2 注册表变量
• 通过创建索引提高 IBM TSOM 历史数据查询性能
• DB2 服务器磁盘空间需求
• DB2 服务器磁盘写入速率
• 发现事件插入过程中的 I/O 瓶颈
• 测试后台数据库的 CMS 查询性能
• 结束语
• 参考资料
• 作者简介
• 建议