运维 on darcyjoven

Oracle运维常用命令

Wed, 14 Oct 2026 00:00:00 +0000

清除查询缓存

1
2
3


ALTER SYSTEM FLUSH SHARED_POOL;
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH GLOBAL CONTEXT;

分析表结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


--① 分析表的所有字段，所有索引，所有索引字段。其中：① = ②
analyze table student compute statistics;
--② 分析表的所有字段，所有索引，所有索引字段。其中：① = ②
analyze table student compute statistics for table for all indexes for all columns;
--③ 只分析所有有索引的字段
analyze table student compute statistics for table for all indexes for all indexed columns;

--④ 抽样估算法
analyze table student estimate statistics sample 20 percent;

--⑤ 删除分析数据
analyze table student delete statistics;
analyze table student delete statistics for table for all indexes for all indexed columns;

--查看表的统计信息
select table_name,num_rows,blocks,empty_blocks from user_tables where table_name='student';

analyze table glaq_t compute statistics;

优化器

优先查询前 25 笔

1
2
3


SELECT /*+ FIRST_ROWS(25) */ employee_id, department_id
FROM hr.employees
WHERE department_id > 50;

强制走索引

1
2
3
4
5


SELECT /*+index(a)*/ * FROM sfb_file
LEFT JOIN sfa_file ON sfa01= sfb01
LEFT JOIN ima_file a ON a.ima01 = sfb05
LEFT JOIN ima_file b ON b.ima01 = sfa03
LEFT JOIN ima_file c ON c.ima01 = sfa27

查询被删除的表

1
2


select object_name,original_name,partition_name,type,ts_name,createtime,droptime
from recyclebin;

恢复删除的表

1
2


flashback table test_drop to before drop;或
flashback table "BIN$hgcd$0" to before drop;

清理临时表空间

1
2
3
4
5
6
7


set linesize 132;
set pagesize 0;
set timing off;
spool drop_tables.sql;
SELECT 'drop table '||OWNER||'.'||TABLE_name||' purge;' FROM dba_tables WHERE tablespace_name='TEMPTABS';
spool off;
@drop_tables.sql;

查询某个时间之前的表状态（闪回）

1
2


select * from sfb_file
as of timestamp to_timestamp('2021-09-22 15:30:00','yyyy-mm-dd hh24:mi:ss')

查询单个 table 占用磁盘空间

1
2
3
4
5
6
7
8


select * from (
 select t.tablespace_name,t.owner, t.segment_name, t.segment_type, sum(t.bytes / 1024 / 1024) mb
 from dba_segments t
 where t.segment_type='TABLE'
	AND tablespace_name ='TEMPTABS'
 group by t.tablespace_name,t.OWNER, t.segment_name, t.segment_type
) t
order by t.mb desc;

在备份中仅恢复部分表

准备号 dmp 备份文件
建立临时测试库

1
2
3
4


sqlplus system/manager@topprod
 create user test1 identified by test1 default tablespace dbs1;
 grant connect,resource to test1;
 commit;

恢复表

1
2


imp system/manager@topprod file=/u3/backup/Wed/exp_KT_20210203.dmp
 fromuser=kt touser=test1 tables=gen_file,eci_file

增加表空间

管理员账号登陆，运行@q_tbsFREE命令查询表空间是否足够
运行@q_datefile查询表空间文件位置
增加合适大小表空间文件

1

alter tablespace xx add datafile 'xxx.dbf' size 4G;

TIPTOP效能处理办法

Wed, 14 Oct 2026 00:00:00 +0000

大量作业都卡顿

当客户反馈所有作业都卡顿时，应当先检查服务器得基本状态，并保留截图，以便后面反馈给SE。

可检查得项目如下：

表空间状况和磁盘使用情况

df -h 查看磁盘使用情况，留意u1和ut已使用百分比，若将近100%，请截图提交SE处理。
检查dsdata/ds1 的控件使用情况，如超过90%可以尝试增加后再查看系统卡顿情况。
检查TEMPTAS表空间使用情况，使用超过90%和可用连续空间不足10M，都会导致作业使用卡顿，增加表空间后再查看卡顿情况。

检查系统负载情况运行命令top后按c

首先查看是否有ERP进程占用资源很高，fglrun或fglrun-bin为ERP，查看%CPU及%MEM占用。有占用高的进程的话和客户确认能否关闭，关闭（客户端无法关掉，可通过kill -9命令关闭）后再查看效能。
查看load average值，三个值表示系统5分钟，15分钟，30分钟负载情况。不超过6~7，为正常。load average/CPU数量如果超过5，表示系统负载很大。遇到这周情况请直接截图提交SE。

检查CPU，内存登占用情况

cpu（s）：cpu 总使用率（不大于40%为负载正常）
运行命令free -h KiB Mem free 要有剩余，且swap使用不多，代表内存空间足够

不建议测试IO性能，测试过程中可能导致正常运行进程闪退，如果怀疑可以交由SE处理

检查数据库响应时间

1
2


 CREATE TABLE test_t (test001 VARCHAR(20));
 DROP TABLE test_t;

运行上述命令查看运行时间，如果DROP TABLE语法执行的时间达到6秒，属于很慢的情况。请直接联系SE处理。
检查AP和DB的网络连接速度
查看是否安装在同一主机
运行命令ps -ef|grep ora_smon

运行命令 ping $FGLSERVER 检测网络延迟，若time 时间超过0.3ms，需要注意网络延迟，如果数值特别高超过300ms，请直接联系客户，请客户先解决网络问题。

需注意

个别作业效能分析步骤

可按照下面步骤排查：

判断是否需要清除ORACLE缓存直接执行作业，如果执行速度和客户反馈的不一样，例如：客户反馈审核要2分钟，还原后重新审核只要几秒钟。

这个时候需要执行一下清除ORACLE缓存的语句，清除复杂SQL的缓存，之后再继续测试效能。

1
2
3


ALTER SYSTEM FLUSH SHARED_POOL;
ALTER SYSTEM FLUSH BUFFER_CACHE;
ALTER SYSTEM FLUSH GLOBAL CONTEXT;

使用效能工具分析作业情况

T100 直接使用r.h工具运行作业分析即可
GP 使用r.r2d+命令运行，如果客户版本没有此工具。需手工开启FGLSQLDEBUG 运行下面两个命令，开启日志开启后，运行命令会将每个连接数据库语句执行状况在后台显示出来。

FGLSQLDEBUG=9

export FGLSQLDEBUG

指定日志目录运行作业

exe2 aapt110 >> aapt110.lixwz.log 2>&1

作业运行后关掉，运行一下命令开始分析日志

$FGLRUN $DS4GL/bin/fgldebug.42r aapt110.lixwz.log

💡

目录下若没有 fgldebug相关文件，需要先将效能工具相关文件上传到此目录，并运行chmod 777 fgldebug* 给与运行权限。

分析效能工具执行结果 RUN_TIME 为总运行时间，AVG_TIME为平均一次运行时间，主要关注这两列。

在进行sql分析之前，先对比标准主机，是否有追单。也关注下相关表索引是否和标准主机一致。
平均运行时间长，可根据PROG_NAME和RUN_LINE 抓取到运行的sql，进行SQL TRACE分析优化
平均运行时间正常，总运行时间长，即单个sql运行次数比较多。程序逻辑需要调整，例如：将FOREACH 操作改成临时表操作，借助数据库完成资料处理。

SQL TRACE 分析

使用plsql按F5进入SQL TRACE

资料比较多sql会通过index索引查询
修改一下，可能就不走索引查询，查询时间也增加了很多。

导致索引失败

索引字段使用函数，如：substr(ima01,1,2)='10'
新建表索引信息还未建立完成，analyze table ima_file compute statistics; 运行分析一下
使用<>、not in 、not exist
表的资料比较少
单独的>、<
like "%_" 百分号在前
单独引用复合索引里非第一位置的索引列，例如：索引为(ima01,ima02,ima03)条件为ima01 = ‘MISC’ ima02 =‘MISC’ ima03 = ‘MISC’ ima02 = 'MISC'
字符型字段为数字时在where条件里不添加引号,(自动走转换函数)
当变量采用的是times变量，而表的字段采用的是date变量时.或相反情况
索引失效，可以考虑重建索引，rebuild online
索引列空值
查询资料已超过总资料一定比例，默认是30%

改写部分sql

not in 、in 、not exist 、exist
可以用left join 或者 inner join 相互替代，那种效率高用哪种。
增加条件条件前置，避免查出资料太多
UPDATE 优化
复杂条件的UPDATE语句，可以优化为MERGE方式。

1
2
3
4
5
6
7


--优化前
UPDATE q802_cfc_tmp o
 SET o.sum_qc= (
 SELECT NVL(SUM(cfc15*cfc18),0) FROM cfc_file c1
 WHERE(c1.cfc05<2021 OR (c1.cfc05=2021 AND c1.cfc06<9))
 AND c1.cfc21=0 AND c1.cfc22 =0 AND c1.cfc01=1
 AND c1.cfc07 = o.cfc07 AND c1.cfc11 = o.cfc11 AND c1.cfc17 = o.cfc17 )

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


--优化后
MERGE INTO q802_cfc_tmp c1 USING (
 SELECT cfc07,cfc11,cfc17,NVL(SUM(cfc15 * cfc18), 0) sum_qc
 FROM cfc_file
 WHERE( cfc05 < 2021
 OR (
 cfc05 = 2021
 AND cfc06 < 9
 )
 )
 AND cfc21 = 0
 AND cfc22 = 0
 AND cfc01 = 1
 GROUP BY cfc07,cfc11,cfc17
 ) o
 ON ( c1.cfc07 = o.cfc07 AND c1.cfc11 = o.cfc11 AND c1.cfc17 = o.cfc17 )
 WHEN MATCHED THEN UPDATE SET c1.sum_qc = o.sum_qc

临时表增加索引，执行中分析表临时表处理的资料比较多时，可以适当增加索引

CREATE INDEX xcck_tmp_i02 ON xcck_tmp (xcckld,xcck003,xcck004,xcck005,xcck047)

如果是INSERT，UPDATE，DELETE语句比较卡顿还可以在执行前分析一下表，看效能是否改善

T100 直接运行函数 cl_db_generate_analyze("xcck_tmp")
TOPGP 可以使用下列命令 EXECUTE IMMEDIATE "analyze table xccd_t estimate statistics"

案例分享

执行次数过多

平均执行时间0.06左右，不算高，但执行次数多达5W多次。

拉取其中sql分析

1
2
3
4
5
6


SELECT MAX(sfe04),MIN(sfe04)
 INTO g_tc_xea[g_cnt].hp_fddrq,g_tc_xea[g_cnt].hp_scfddrq
 FROM sfe_file,sfb_file
 WHERE sfbud02 = g_tc_xea[g_cnt].tc_xea01
 AND (sfb01 LIKE '538%' OR sfb01 LIKE '540%')
 AND sfb01 = sfe01

没有索引，将sfbud02增加索引，效果并不好（增加索引后效果不好记得删除）
语句中有OR也有like，但无法进行下一步优化
查看FOREACH 是直接通过临时表取值，可以考虑直接将需要的字段再中间中处理所以将所有SELECT语句改为更新临时表字段形式，然后FOREACH直接取值即可（临时表可能需要增加字段）
在FOREACH执行前先更新中间表
优化后，总执行时间已经减少了很多。
调整后的MERGE只需要执行一次，时间在0.1秒。

流程调整优化

用户反馈，此作业批量抛转时，速度很慢。

查询需要1分多钟
查询出结果后，勾选收款单号，每次都需要转圈很长时间才可以继续勾选

根据效能工具结果优化部分查询sql 将in 改成 left join 形式，速度有所改善，保留。
发现每次勾选收款单号之后，都会重新运行一遍单身显示得函数，所以导致批量抛转操作很慢。注释掉勾选后重新查询得逻辑，速度明显快很多，勾选不再需要等待。客制作业经常出现此类问题，测试时资料比较少，被忽略掉，这类问题优化时有限考虑mark掉不必要得流程。

磁盘空间导致复制账套失败解决办法

Wed, 14 Oct 2026 00:00:00 +0000

u1 磁盘空间不足导致复制账套失败

情况适用于以下情况：

复制账套时，报错

EXP-00002: error in writing to export file

最后导出失败

如何判断是否是磁盘空间不足的 2 种方法

1.重新运行一遍 aooi931 建立 sch。

若提示修改 FGLPROFILE,直接 vi $FGLPROFILE 删除掉复制的新账套信息。一般是最后几行。

再次生成 sch。

运行过程中观察磁盘空间，df -h，如果/u1 磁盘空间一直增长到 100%，即可判断是磁盘空间不足。 2.查看复制的来源账套的最近一次备份，解压之后的 dmp 文件如果大于 u1 剩余可用空间，就可判断磁盘空间不足

修改 createsch 脚本

createsch 默认目录

/u1/topprod//tiptop/ora/bin/createsch

将 exp 和 imp 语句中的文件位置修改为磁盘空间足够的目录

复制账套只用到第四条命令，可参考文件 createsch 备注为 lixwz

1
2
3
4
5


exp $source/$ans5@$ORACLE_SID owner=${source} file=/u2/topprod/tiptop/tmp/${source}.dmp log=$TOP/tmp/exp_${source}.log

imp system/$ans2@$ORACLE_SID fromuser=$source touser=$1 file=/u2/topprod/tiptop/tmp/${source}.dmp log=$TOP/tmp/imp_$1.log

rm -f /u2/topprod/tiptop/tmp/${source}.dmp

上传完文件，注意文件的权限，用 chmod 修改