用ps命令查看是否有dasusr1后台进程
#ps -ef | dasusr1
请确保管理服务器已经启动,如果没有启动,则按以下步骤启动管理服务器:
用ps命令查看是否有db2sysc后台进程
#ps -ef | db2sysc
也可以以DB2实例所有者登录,通过发出db2start命令来确保启动了实例(如果实例已经启动,则会告知SQL1026N 数据库管理器已激活;否则,将把实例启动起来)
以db2实例所有者登录
#db2 list tablespaces show detail //在单分区上查看表空间的状态,正常返回0x0000
# db2_all list tablespaces show detail //在所有分区上查看表空间的状态
可以使用LIST TABLESPACES 命令确定连接数据库中表空间的当前状态,可以使用SHOW DETAIL选项查看表空间的详细信息。比如,我们连上SAMPLE数据库,执行list tablespaces show detail ,可以看到状态返回值是0x0000,此时,使用db2tbst可以查看状态编号对于的状态含义,具体语法如下:
db2tbst <tablespace state> 可以查看编号所代表的状态
db2tbst 命令接收十六进制的状态值,并返回相应的表空间状态。例如,命令 db2tbst 0x0008 返回 State = Load Pending 。而该十六进制的状态值反过来又是 LIST TABLESPACES 命令输出的组成部分。表空间的外部可见状态是由单个状态值的十六进制总和构成的。例如,如果表空间的状态是 Backup Pending和 Load in Progress,那么所返回的十六进制值就是 0x20020(0x00020 + 0x20000)
查询系统目录视图以获得关于数据库的有用信息。例如,下面的语句使用 NOT LIKE 断言,返回在 SYSCAT.TABLES 中有项的所有用户定义的表的名称,以及每个表的列数和表的状态(N = 正常;C = 待审核(check pending))
#db2 select tabname, colcount, status FROM syscat.tables WHERE tabschema NOT LIKE ‘SYS%’ ORDER BY tabname
也可以使用load query命令查看单个表的状态,比如对表TEST1,我们可以发出如下命令:
#db2 load query table test1
查看数据库活动日志目录是否已满,活动日志目录可以使用get db cfg查看,注意一定不要手工删除活动日志
#df -k
查看SMS表空间对应的容器目录空间是否满了
#df -k
查看DMS表空间中是否还有可用页
#db2 list tablespaces show detail //在单分区上查看表空间的是否还有可用页
# db2_all list tablespaces show detail //在所有分区上查看表空间是否还有可用页
请检查TSM或其他存储管理软件是否正常,以及磁带机是否运行正常。
请查看TSM或第三方存储管理软件,看备份映像文件是否完整的保存到了磁带机上了,想在DB2上查看备份情况,可以使用LIST命令
# db2 list history backup all for 数据库名
请确保活动日志目录下没有的日志文件都已经正确归档到了带机上(查看TSM或第三方存储管理软件)。
查看活动目录里的日志文件:
#ls -l
# db2 get snapshot for bufferpools on 数据库名
查看缓冲池的命中率,看其是否低于95%(命中率越高越好)
# db2 get snapshot for bufferpools on 数据库名 > log.txt
用grep命令查看” Number of executions”执行次数最频繁的语句,看其命中率是否正常。
比如:
grep -n ” Number of executions” snap.out | grep -v “= 0” | sort -k 5,5rn | more
#db2 list applications show detail
看这些连接的情况,看有没有不合适的IP连上来,或者不被允许的第三方工具连上来,比如一些第三方工具连上来会对表进行锁定,影响业务系统正常运行,这个时候可以用FORCE APPLICATIONS (应用程序句柄)停下来。
# db2 get snapshot for all on 数据库名 > log.txt
用grep命令查看输出的文件中是否有死锁的记录,比如
grep -n “Deadlocks detected” log.txt | grep -v “= 0” | more
#db2 runstats on table 表名 and index all
对系统表以及变化比较频繁的表运行统计信息,建议写成shell脚本自动运行。
使用REORGCHK命令,通过统计数据检查表是否需要重组,语法如下:
REORGCHK [UPDATE | CURRENT ]STATISTICS ON [TABLE SYSTEM| TABLE USER | TABLE ALL | TABLE table_name | SCHEMA schema_name]
UPDATE STATISTICS: 更新表的统计数据,根据该统计数据判断是否需要重组表
CURRENT STATISTICS:根据当前表统计数据判断是否需要重组表
TABLE table_name : 对单个表进行分析
TABLE ALL: 对数据库所有的表进行分析
TABLE SYSTEM: 对系统表进行分析
TABLE USER : 对当前用户模式下的所有表进行分析
#db2 reorgchk update statistics on table all
#db2 reorg table 表名 //通过重构行来消除“碎片”数据
#db2 reorg indexes all for table 表名 //只重组索引
比如:
reorg table db2inst1.org index by_id
将根据索引by_id,如果不加INDEX选项将重组表和所有的索引
reorg table db2inst1.org index by_id use tempspace1
使用指定的临时表空间重组表
表重组完成后需要进行RUNSTATS。另外,记住在分区数据库环境中,如果想在所有节点运行命令,需要使用db2_all命令。
请至少每月查看一次db2diag.log文件,看其中是否有异常。
通过TSM或第三方存储管理软件,查看备份和归档日志是否都保存好了,在数据库级别查看备份,可以使用:
# db2 list history backup all for 数据库名
通过快照监控器,抓取数据库的信息,分析数据库性能是否合理:
# db2 get snapshot for all on 数据库名 > log.txt
# db2level
DB2 的活动日志文件不能被删除。一旦 DB2 的活动日志文件被删除,或者所在的存储设备出现问题,则不可避免地造成 DB2 数据库系统宕机。
在归档日志模式下,如果没有使用自动归档方式,则存储的日志文件会不断增多,有可能造成日志所在的文件系统空间满。 当这种情况发生时,会根据参数 BLK_LOG_DSK_FUL 的配置而有不同的现象:
1)如果该参数启用,则 DB2 数据库可继续读操作,但是写操作会挂起
2)如果该参数没有启用,则 DB2 数据库会停止工作
两种情况下,都需要到日志所在的文件系统添加了空间才恢复正常。
DB2数据库通过日志文件维护数据的完整性和一致性。DB2 数据库的日志空间可通过如下公式计算:
日志空间 = (主日志文件 + 二级日志文件) * 日志文件尺寸
其中:
由于数据库的代码页在数据库创建之后是无法修改的,所以在创建数据库时一定要选择正确的代码页。
错误的数据库代码页会造成 JDBC/ODBC 访问时中文字段被截断(包括控制中心),这种情况需要重建数据库以修改数据库代码页。
从全局规划来说,如果应用需要访问多个数据库,那么这多个数据库的代码页应该是一致的。
许可证过期会造成不必要的服务中断,所以在 DB2 安装完毕后,建议检察许可的安装情况
在数据库创建好之后,调整系统时间会造成数据库内部时间戳的异常。数据库中一些对象和时间相关,一旦时间不准确要调整需要很小心。错误的时间调整可能会造成很多问题,如:
1)某些对象失效,例如 :
SQL0440N,找不到具有兼容自变量的类型为 “<例程类型>” 的名为 “<例程名>” 的已授权例程
2)数据库日志逻辑错误 -> 宕机
3)常见错误 – 只调整时间,未调整时区
在实例目录下chown (chmod) -R 会造成
以脱机方式重组表是整理表碎片的最快方法。重组可减少表所需的空间量并提高数据访问和查询性能。
必须具有 SYSADM、SYSCTRL、SYSMAINT 或 DBADM 权限,或者必须具有对表的 CONTROL 权限才能重组表。必须具有数据库连接才能重组表。
标识需要重组的表之后,可以对这些表运行 REORG 实用程序,并且可以选择对在这些表上定义的任何索引运行该实用程序。
db2 reorg table test.employee
要使用临时表空间 mytemp 重组表,请输入:
db2 reorg table test.employee use mytemp
要重组表并根据索引 myindex 对行进行重新排序,请输入:
db2 reorg table test.employee index myindex
call sysproc.admin_cmd (‘reorg table employee index myindex’)
在重组表之后,应收集有关表的统计信息,以便优化器具有最准确的数据来评估查询访问方案。
通过删除和插入操作对表进行更新后,索引的性能会降低,其表现方式如下:
叶子页被分段之后,由于必须读取更多的叶子页才能访存表页,因此 I/O 操作成本会增加。
叶子页出现不良集群情况后,顺序预取操作的效率将降低,因此会导致更多的 I/O 等待。
在此情况下应重组索引。
如果在创建索引时设置了 MINPCTUSED 参数,则在删除某个键且可用空间小于指定的百分比时,数据库服务器会自动合并索引叶子页。此过程称为联机索引整理碎片。但是,要复原索引集群和可用空间以及降低叶级别,请使用下列其中一种方法:
因为此方法允许用户在重建表索引期间对表进行读写操作,所以在生产环境中可能需要选择此方法。
联机索引重组
在使用 ALLOW WRITE ACCESS 选项运行 REORG INDEXES 命令时,如果同时允许对指定的表进行读写访问,则会重建该表的所有索引。进行重组时,对基础表所作的任何将会影响到索引的更改都将记录在 DB2® 日志中。另 外,如果有任何内部内存缓冲区空间可供使用,则还将这些更改放在这样的内存空间中。重组将处理所记录的更改以便在重建索引时与当前写活动保持同步更新。内 部内存缓冲区空间是根据需要从实用程序堆中分配的指定内存区域,它用来存储对正在创建或重组的索引所作的更改。使用内存缓冲区空间使索引重组操作能够通过 这样的方式来处理更改,即先直接从内存读取,然后读取日志(如有必要),但读取日志的时间要晚得多。在重组操作完成后,将释放所分配的内存。重组完成后, 重建的索引可能不是最佳集群的索引。如果为索引指定 PCTFREE,则在重组期间,每页上均会保留相应百分比的空间。
对于分区表,支持对各个索引进行联机索引重组和清除。要对各个索引进行重组,指定索引名:REORG INDEX index_name for TABLE table_name
对于空间索引或多维集群(MDC)表,不支持采用 ALLOW WRITE 方式的联机索引重组。
注: REORG INDEXES 命令的 CLEANUP ONLY 选项不能完全重组索引。CLEANUP ONLY ALL 选项将除去那些标记为“删除”且被认为要落实的键。此外,它还将释放所有标记为“删除”且被认为要落实的键所在的页。在释放页后,相邻的叶子页将会合并,前提是这样做可以在合并页上至少留出 PCTFREE 可用空间。PCTFREE 是指在创建索引时为其定义的可用空间百分比。CLEANUP ONLY PAGES 选项仅删除那些标记为“删除”且被认为要落实的所有键所在的页。
使用 CLEANUP ONLY 选项对分区表的索引进行重组时,支持任何访问级别。如果未指定 CLEANUP ONLY 选项,则缺省访问级别 ALLOW NO ACCESS 是唯一支持的访问级别。
REORG INDEXES 具有下列要求:
在发出 CREATE TABLE 语句时,考虑在大型表空间中重组索引。
REORG INDEXES 需要记录其活动。因此,重组可能会失败,尤其是在系统繁忙和记录其他并发活动时。
注: 如果具有 ALLOW NO ACCESS 选项的 REORG INDEXES ALL 命令运行失败,则会标记索引无效并且此项操作不可撤销。但是,如果具有 ALLOW READ ACCESS 选项的 REORG 命令或具有 ALLOW WRITE ACCESS 选项的 REORG 命令运行失败,则可以复原原来的索引对象。
RUNSTATS 命令收集表、索引和统计信息视图的统计信息,以为优化器提供准确信息进行访问方案选择。
在下列情况下,使用 RUNSTATS 实用程序来收集统计信息:
注:
在先前版本的 DB2® 中,此命令使用了 NODEGROUP 关键字,而不是 DATABASE PARTITION GROUP 关键字。
要提高 RUNSTATS 性能并保存用来存储统计信息的磁盘空间,考虑仅指定应该收集其数据分布统计信息的列。
理论上,您应在运行统计信息之后重新绑定应用程序。如果查询优化器具有新的统计信息,则它可以选择不同的访问方案。
如果您没有足够的时间一次收集全部的统计信息,则可以运行 RUNSTATS 来每次仅更新几个表、索引或统计信息视图的统计信息,并轮流完成该组对象。如果对选择性部分更新运行 RUNSTATS 期间由于表上的活动而产生了不一致性,则在查询优化期间将发出警告消息(SQL0437W,原因码 6)。例如,如果执行 RUNSTATS 来收集表分布统计信息,以及在某个表活动后,再次执行 RUNSTATS 来收集该表的索引统计信息,则可能发生这种情况。如果由于表上的活动产生了不一致并且在查询优化期间检测到这些不一致,则发出该警告消息。当发生这种情况时,应再次运行 RUNSTATS 来更新分布统计信息。
要确保索引统计信息和表同步,执行 RUNSTATS 来同时收集表和索引统计信息。索引统计信息保留自上次运行 RUNSTATS 以来收集的大部分表和列的统计信息。如果自上次收集该表的统计信息以来已对该表做了大量修改,则只收集该表的索引统计信息将使两组统计信息不能在所有节点上都同步。
对生产系统调用 RUNSTATS 可能会对生产工作负载的性能产生负面影响。RUNSTATS 实用程序现在支持调速选项,在执行较高级别的数据库活动期间,可以使用调速选项来限制执行 RUNSTATS 的性能影响。
在分区数据库环境中收集表的统计信息时,RUNSTATS 仅收集执行该命令的数据库分区上的表的统计信息。将此数据库分区的 RUNSTATS 结果推广到其他数据库分区。如果执行 RUNSTATS 的数据库分区不包含特定表的一部分,则将请求发送到数据库分区组中包含该表一部分的第一个数据库分区。
收集统计信息视图的统计信息时,将收集所有包含该视图引用的基本表的数据库分区的统计信息。
考虑以下技巧来提高 RUNSTATS 的效率和已收集的统计信息的有效性:
可从 CLP 使用 GET HEALTH SNAPSHOT 命令来捕获运行状况快照。该命令语法支持检索运行状况监视器监视的不同对象类型的运行状况快照信息。
先决条件
必须具有实例连接才能捕获运行状况快照。如果没有实例连接,则创建缺省实例连接。要获取远程实例的快照,必须先连接至该实例。
过程
要使用 CLP 捕获数据库运行状况快照
在以下示例中,将在启动数据库管理器之后立即捕获数据库管理器级别运行状况快照。
db2 get health snapshot for dbm
db2 get health snapshot for db on sample at dbpartitionnum 2
要对所有分区上的所有应用程序捕获数据库快照,请发出以下命令:
db2 get health snapshot for db on sample global
以下命令捕获的运行状况快照带有附加详细信息,包括公式、附加信息和运行状况指示器历史记录:
db2 get health snapshot for db on sample show detail
要对列示了所有集合对象的数据库捕获运行状况快照,请发出以下命令:
db2 get health snapshot for db on sample with full collection
发布者:全栈程序员栈长,转载请注明出处:https://javaforall.cn/100520.html原文链接: