informix1文档格式.docx
- 文档编号:20313163
- 上传时间:2023-01-21
- 格式:DOCX
- 页数:17
- 大小:26.92KB
informix1文档格式.docx
《informix1文档格式.docx》由会员分享,可在线阅读,更多相关《informix1文档格式.docx(17页珍藏版)》请在冰豆网上搜索。
5)导出一个存储过程定义到文件db.sql
your_procedure_name
6)如果导出更多的表的信息(EXTENT...)
7)导出数据库中对用户或角色的授权信息
8)导出数据库中的同义词
all
1
onstat工具
1.1
监控虚拟处理器和线程
onstat
–g
ath
显示有关线程和处理器类的信息
glo
显出当前每个处理器的信息以及有关每个处理器类的累积的统计信息
ioq
使用onstat
ioq可以确定你是否要分配附加的AIO虚拟处理器。
监视AIO
vp的gdf队列的长度,队列一贯短时表示对磁盘设备的处理速度与发生请求的速度一样快。
如果gdf队列持续很长,考虑增加AIO
vp的数目。
wai
显示等待状态的线程
act
显示活动状态的现场
rea
监视就绪队列中的线程
sle
显示睡眠状态的线程
1.2
操作系统进程与数据库session的关系
1)
使用操作系统命令(例如topas)查看最繁忙的oninit进程,记录它的pid
2)
用onstat
glo查看vp
class,看相应进程里运行的是那个vp(用pid去匹配)。
确定瓶颈是在那一类vp上(比如是在cpu
vp上还是在aio
vp上)。
记录vp,class。
3)
act(或onstat
ath)查看相应vp里运行的是那个线程(用vp
class去匹配),记录它的tid,rstcb。
4)
ses
ses_id检查session信息(用tid,rstcb去匹配)
下面的shell用于获得所有session信息
!
/usr/bin/ksh
###############################################################################
#
#
Module:
ses_all.sh
Author:
Henry
Cheung
Description:
Get
all
sessiong
information
History
Date
Name
Description.................
07/30/2004
Cheung
Start
Program
-g
|
grep
-v
IBM
|grep
session
id
awk
'
$1}'
while
read
SES_ID
do
$SES_ID
done
1.3
监控共享内存
–o
捕获共享内存的静态快照用于今后的分析和比较
seg
显示每个共享内存段的信息。
一般用于检查有几个虚拟内存段。
如果虚拟内存段过多,考虑调整SHMVIRSIZE,和SHMADD参数。
–s
获取锁存器的信息
–p
显示数据库活动的统计信息。
比如cached的读写命中率。
如果读写命中率较低,考虑调整BUFFERS参数。
ovuserthread-用户尝试超过用户最大线程最大的次数,ovbuff数据库服务器无法找到共享内存缓冲区的次数,
1.4
监视磁盘使用
-d
检查数据库dbspace、chunk使用情况。
配合topas等系统命令,监控是否某个物理硬盘出现I/O瓶颈。
iof
显示每个块的读取、写入的次数
1.5
其他
方法:
onstat
目的:
检查数据库服务器运行了多长时间,总共占用了多少内存。
–c
或
oncheck
–pr
检查数据库服务器当前使用的配置文件
env
检查数据库服务器当前使用的环境变量
-l
检查逻辑日志情况。
–m或vi
online.log
检查数据库日志,包括检查点完成时间,是否有异常等。
(session
id),
sql
检查session状况
–u
显示库用户活动信息
–x
显示数据库服务器上的事务信息
2
oncheck工具
-cr
检查保留页
–ce
检查统空间使用情况
–cc
database
检查应用数据库的系统表
–ci,
-cI
检查数据库的索引情况,注意此命令会影响生产系统且耗时较长,应在适当的时候检查。
–cd,
–cD
检查数据库的数据情况,,注意此命令会影响生产系统且耗时较长,应在适当的时候检查。
3
使用SMI
3.1
dbspace使用情况
--FileName:
dbspaces.sql
--dbspace使用情况:
输入dbspace
name,
allocated,
free,
percent
of
used
unload
to
dbs.txt
delimiter
"
SELECT
name[1,15]
dbspace,
SUM(chksize)
SUM(nfree)
free,
ROUND(((SUM(chksize)
-
SUM(nfree))/SUM(chksize))*100)
pcused
FROM
sysmaster:
sysdbspaces
d,
syschunks
c
WHERE
d.dbsnum
=
c.dbsnum
GROUP
BY
1
ORDER
4
DESC
及时监控dbspace的使用情况,以便分配新的空间给数据库使用
3.2
dbspace
I/O
dbs_io.sql
--dbspace、chunk
I/O:
path,
disk
reads,
writes
UNLOAD
TO
dbs_io.txt
DELIMITER
first
10
d.name,
fname
path_name,
SUM(pagesread)
diskreads,
SUM(pageswritten)
diskwrites
syschkio
c,
k,
d
k.dbsnum
AND
k.chknum
c.chunknum
1,
2
监视是否存在某个dbspace
I/O较高的情况,如果有就要考虑更为合理的数据分布和硬盘划分。
3.3
统计数据库占用的空间
database_size.sql
--统计数据库占用的空间:
database_name,
size
dbsname[1,15]
SUM(pe_size)
sysptnext,
OUTER
systabnames
pe_partnum
partnum
3.4
表扩展块情况
extents.sql
--获取系统中extents最多的表的表名,所在的数据库名,extents的数量
--sysextents表9.2版本和9.4版本的结构有不同,但不影响本sql执行
extents.txt
FIRST
20
t.dbsname,
t.tabname,
count(*)
systabnames
t,
sysextents
e
t.dbsname
e.dbsname
t.tabname
e.tabname
t.tabname[1,3]
sys"
1,2
如果发现表的extents数量过多,就要考虑调整extents的大小,并且重建表。
3.5
表I/O
tab_io.sql
--table
I/P:
dbsname,
tabname,
writes,
io
sum
tab_io.txt
5
(isreads
+
pagreads)
(iswrites
pagwrites)
diskwrites,
pagreads
iswrites
disk_io
sysptprof
tabname[1,3]
监视是否存在某张表I/O较高的情况,如果有就要考虑更为合理的数据分布和硬盘划分。
3.6
表空间的使用情况
tab_space.sql
--表空间的使用情况:
table
allocated_space,
used_space,
free_space
--针对每个应用库
tab_used.txt
t.tabname[1,20]
table_name,
Cast(dbinfo(
DBSPACE"
t.partnum
)
as
char(10))
p.nptotal
allocated_space,
p.npused
used_space,
(p.nptotal
p.npused)
free_space,
ROUND((p.npused/p.nptotal)*100)
percent_used
APPDB:
systables
a,
sysptnhdr
p
a.partnum
p.partnum
t.partnum
tabid
>
99
1,2,3,4,5
如果表空间分配的较多而使用的较少,就要考虑重建表。
3.7
索引层数
idx_lvl.sql
--索引层:
index
levels
--应用库
i.idxname,
i.levels
sysindexes
i
t.tabid
i.tabid
当索引层数超过4层就要考虑是否需要重建索引。
3.8
索引唯一性
idx_unq.sql
--索引唯一性:
rows,
unique,
unique
--i.nunique/t.nrows有可能会除零,
idx_unq.txt
t.nrows,
i.nunique
=i.tabid
{
i.nunique,
(i.nunique/t.nrows)*100
pcniq
DESC,
}
索引唯一性的百分率越高,索引的唯一性就越高,性能就越好。
为了避免因索引重复程度很高而引起的性能瓶颈,您可以使用复合索引来替换原来的索引,复合索引结合了重复程度很高的列与唯一性比较高的列。
3.9
顺序扫描
seq_scans.sql
--顺序扫描:
database
number
total
sequence
scans
seq_scans.txt
p.dbsname,
p.tabname,
sum(p.seqscans)
tot_seqscans
sysptprof
p,
t
p.dbsname
NOT
LIKE
sys%"
APPDB
p.tabname
t.tabname
1,2,3
DESC,4
如果一个具有几千甚至几百万行大表的顺序扫描数很高,那么您可能需要考虑向该表添加一些索引,或者考虑使用程序伪指令来强制内部查询优化器为访问该表中的数据选择索引而不是顺序扫描。
3.10
获取session信息
可以从syssespro(各用户操作计数),syssesions(对每个已连接用户的描述)表中获取sessions信息。
sessions.sql
--sessions信息:
id,
user
host
access,
locks,
scans,
sorts,
memory
sorts
s.sid,
s.username,
s.hostname,
(isreads+iswrites+bufreads+bufwrites+pagreads+pagwrites)
access,
locksheld,
seqscans,
total_sorts,
dsksorts,
((total_sorts
dsksorts)/total_sorts)*100
pct_memsorts
syssessions
s,
syssesprof
f
s.sid=f.sid
4
如果一个session有过多的顺序扫描,或占用过多的锁资源,或使用了较多的disk
sorts就需要关注这个session。
3.11
sessions持有lock的情况
lock.sql
--sessions持有lock的情况:
sid,
username,
hostname,
lock
type
owner,
syslocks
l
sid
owner
tabname
如果在锁使用方面存在某些冲突,例如某个用户需要对已被别的用户锁定的表进行专有访问,那么您可以方便地确定该锁的所有者,并根据用户的优先级发出
onmode
-z
命令来杀死会话,然后释放该锁;
这个编号是从上面输出中的
owner
字段中获取的;
请注意,只有用户“Informix”可以执行该命令。
3.12
锁信息
--锁信息:
数据库名,表名,该表占有互斥锁的个数
lock_count.sql
COUNT(*)
type
%X%"
3
性能瓶颈时应急方法
4.1
收集系统运行信息
收集全面的系统运行信息,以便今后分析问题所在。
–a,onstat
all,并保留输出信息到文件中。
保留online.log。
如果数据库宕机有core文件生成,请保留core文件。
4.2
数据库宕机
重启数据库保证关键业务运行。
保留online.log,core文件。
查看online.log,core文件,初步判断宕机原因,并于IMB技术支持联系。
如果重启失败,考虑切换到备份机。
4.3
系统运行突然变慢,系统资源被占用过多
4.3.1
检查系统资源
首先用topas,nmon,sar,
vmstat,iostat等命令检查CPU,内存、硬盘资源的使用情况。
topas
Topas
Monitor
for
host:
S1_C_HZ_SHUJUKU
EVENTS/QUEUES
FILE/TTY
Tue
Jul
27
13:
01:
26
2004
Interval:
Cswitch
1907
Readch
2750
Syscall
7513
Writech
581
Kernel
2.2
|#
Reads
21
Rawin
User
62.0
|##########
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- informix1