Loading [MathJax]/jax/input/TeX/config.js
前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
社区首页 >专栏 >案例:是谁用了我的临时表空间?

案例:是谁用了我的临时表空间?

作者头像
Alfred Zhao
发布于 2023-08-24 09:27:53
发布于 2023-08-24 09:27:53
26000
代码可运行
举报
运行总次数:0
代码可运行

环境:RHEL 6.5 + Oracle 11.2.0.4 RAC + ADG

起初发现自己的ADG测试环境不再同步,进一步分析是DATA磁盘组空间耗尽导致的,可是最近在磁盘组上的数据库都没有做过什么测试,且测试磁盘组一直都留有2G+剩余空间,那是什么导致突然没空间了呢? 经过查询dba_data_files发现数据文件的确没有什么增长,但查询dba_temp_files发现临时文件空间增长严重。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
sys@DEMO> set lines 180
sys@DEMO> select file_id, file_name, tablespace_name, bytes/1048576 "MB" from dba_temp_files;

   FILE_ID FILE_NAME                                               TABLESPACE_NAME                        MB
---------- ------------------------------------------------------- ------------------------------ ----------
         1 +DATA/demo/tempfile/temp.264.1018829761                 TEMP                                 2701
         2 +DATA/demo/tempfile/temp_jingyu.258.1018830415          TEMP_JINGYU                            30

sys@DEMO> 

或者直接从asmcmd中也可以清楚看到TEMP文件占用大量空间:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
ASMCMD> pwd
+data/demo/tempfile
ASMCMD> ls -ls
Type      Redund  Striped  Time             Sys  Block_Size  Blocks       Bytes       Space  Name
TEMPFILE  UNPROT  COARSE   NOV 16 09:00:00  Y          8192  345729  2832211968  2834300928  TEMP.264.1018829761
TEMPFILE  UNPROT  COARSE   NOV 04 10:00:00  Y          8192    3841    31465472    32505856  TEMP_JINGYU.258.1018830415
ASMCMD> du
Used_MB      Mirror_used_MB
   2734                2734

基本已经确认了就是temp文件占用了空间,导致DATA磁盘组空间耗尽,那么是谁使用了临时表空间呢?根据DG不同步的时间点初步定位是在11-16号这天,我们可以直接根据DBA_HIST_ACTIVE_SESS_HISTORY中的TEMP_SPACE_ALLOCATED字段进一步定位:

DBA_HIST_ACTIVE_SESS_HISTORY TEMP_SPACE_ALLOCATED Amount of TEMP memory (in bytes) consumed by this session at the time this sample was taken

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select instance_number, to_char(sample_time,'mm-dd hh24:mi'), sum(TEMP_SPACE_ALLOCATED) from dba_hist_active_sess_history where sample_time > to_date('11-16 00:00','mm-dd hh24:mi') and sample_time < to_date('11-17 00:00','mm-dd hh24:mi')  group by instance_number, to_char(sample_time,'mm-dd hh24:mi')
    order by 1, 2;
    省略部分输出..

              2 11-16 08:43
              2 11-16 08:44
              2 11-16 08:50                 574619648
              2 11-16 08:51                1743781888
              2 11-16 08:52                3379560448
              2 11-16 08:53                5015339008
              2 11-16 08:54                6727663616
              2 11-16 08:55                8554283008
              2 11-16 08:56                1.0105E+10
              2 11-16 08:57                1.1897E+10
              2 11-16 08:58                1.3597E+10
              2 11-16 08:59                1.4906E+10
              2 11-16 09:00                2787115008
              2 11-16 09:02
              2 11-16 09:04

进一步细化时间,秒级别(注意DBA_HIST_ACTIVE_SESS_HISTORY默认采样数据间隔为10s)

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select instance_number, to_char(sample_time,'mm-dd hh24:mi:ss'), sum(TEMP_SPACE_ALLOCATED) from dba_hist_active_sess_history where sample_time > to_date('11-16 08:43','mm-dd hh24:mi') and sample_time < to_date('11-16 09:02','mm-dd hh24:mi')  group by instance_number, to_char(sample_time,'mm-dd hh24:mi:ss')
    order by 1, 2;

INSTANCE_NUMBER TO_CHAR(SAMPLE SUM(TEMP_SPACE_ALLOCATED)
--------------- -------------- -------------------------
省略部分输出..
              2 11-16 08:44:29
              2 11-16 08:50:29                  35651584
              2 11-16 08:50:39                 134217728
              2 11-16 08:50:49                 182452224
              2 11-16 08:50:59                 222298112
              2 11-16 08:51:10                 266338304
              2 11-16 08:51:20                 318767104
              2 11-16 08:51:30                 359661568
              2 11-16 08:51:40                 386924544
              2 11-16 08:51:50                 412090368
              2 11-16 08:52:00                 445644800
              2 11-16 08:52:11                 492830720
              2 11-16 08:52:21                 545259520
              2 11-16 08:52:31                 591396864
              2 11-16 08:52:41                 628097024
              2 11-16 08:52:51                 676331520
              2 11-16 08:53:01                 723517440
              2 11-16 08:53:11                 771751936
              2 11-16 08:53:21                 819986432
              2 11-16 08:53:31                 866123776
              2 11-16 08:53:41                 897581056
              2 11-16 08:53:51                 936378368
              2 11-16 08:54:01                 991952896
              2 11-16 08:54:11                1048576000
              2 11-16 08:54:21                1099956224
              2 11-16 08:54:31                1145044992
              2 11-16 08:54:41                1194328064
              2 11-16 08:54:51                1247805440
              2 11-16 08:55:01                1301282816
              2 11-16 08:55:12                1354760192
              2 11-16 08:55:22                1401946112
              2 11-16 08:55:32                1449132032
              2 11-16 08:55:42                1502609408
              2 11-16 08:55:52                1544552448
              2 11-16 08:56:02                1572864000
              2 11-16 08:56:12                1611661312
              2 11-16 08:56:22                1657798656
              2 11-16 08:56:32                1704984576
              2 11-16 08:56:42                1754267648
              2 11-16 08:56:52                1803550720
              2 11-16 08:57:02                1853882368
              2 11-16 08:57:12                1906311168
              2 11-16 08:57:22                1957691392
              2 11-16 08:57:32                2012217344
              2 11-16 08:57:42                2058354688
              2 11-16 08:57:52                2108686336
              2 11-16 08:58:02                2153775104
              2 11-16 08:58:12                2203058176
              2 11-16 08:58:23                2253389824
              2 11-16 08:58:33                2298478592
              2 11-16 08:58:43                2332033024
              2 11-16 08:58:53                2356150272
              2 11-16 08:59:03                2383413248
              2 11-16 08:59:13                2403336192
              2 11-16 08:59:24                2443182080
              2 11-16 08:59:34                2487222272
              2 11-16 08:59:44                2550136832
              2 11-16 08:59:54                2638217216
              2 11-16 09:00:04                2786066432
              2 11-16 09:00:14                   1048576
              2 11-16 09:00:24

81 rows selected.

实例2从11-16 08:50:29 开始,到 09:00:04 结束,temp增长到2G+(2786066432),那么具体是哪些SQL消耗的呢? 上面的查询可以直接加入sql_id字段定位,发现都是同一个SQL导致的:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select instance_number, to_char(sample_time,'mm-dd hh24:mi:ss'), sql_id, sum(TEMP_SPACE_ALLOCATED) from dba_hist_active_sess_history where sample_time > to_date('11-16 08:43','mm-dd hh24:mi') and sample_time < to_date('11-16 09:02','mm-dd hh24:mi')  group by instance_number, to_char(sample_time,'mm-dd hh24:mi:ss'), sql_id
    order by 1, 2;

              2 11-16 08:59:24 auyf8px9ywc6j                2443182080
              2 11-16 08:59:34 auyf8px9ywc6j                2487222272
              2 11-16 08:59:44 auyf8px9ywc6j                2550136832
              2 11-16 08:59:54 auyf8px9ywc6j                2638217216
              2 11-16 09:00:04 auyf8px9ywc6j                2786066432

SQL_ID auyf8px9ywc6j 对应的文本为:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
select sql_text from dba_hist_sqltext where sql_id = 'auyf8px9ywc6j';

SQL_TEXT
--------------------------------------------------------------------------------
WITH SNAP_RANGES AS (SELECT /*+ FULL(ST) */ SN.DBID ,SN.INSTANCE_NUMBER ,SN.STAR
TUP_TIME ,ST.STAT_ID ,ST.STAT_NAME ,MIN(SN.SNAP_ID) AS MIN_SNAP ,MAX(SN.SNAP_ID)
 AS MAX_SNAP ,MIN(CAST(BEGIN_INTERVAL_TIME AS DATE)) AS MIN_DATE ,MAX(CAST(END_I
NTERVAL_TIME AS DATE)) AS MAX_DATE FROM DBA_HIST_SNAPSHOT SN ,WRH$_STAT_NAME ST
WHERE SN.BEGIN_INTERVAL_TIME > TRUNC(SYSDATE) - 7 AND SN.END_INTERVAL_TIME < TRU
NC(SYSDATE) AND SN.DBID = ST.DBID AND ST.STAT_NAME IN ('DB time', 'DB CPU') GROU
P BY SN.DBID,SN.INSTANCE_NUMBER,SN.STARTUP_TIME,ST.STAT_ID,ST.STAT_NAME ) ,DELTA
_DATA AS (SELECT SR.DBID ,SR.INSTANCE_NUMBER ,SR.STAT_NAME ,CASE WHEN SR.STARTUP
_TIME BETWEEN SR.MIN_DATE AND SR.MAX_DATE THEN TM1.VALUE + (TM2.VALUE - TM1.VALU
E) ELSE (TM2.VALUE - TM1.VALUE) END AS DELTA_TIME FROM WRH$_SYS_TIME_MODEL TM1 ,
WRH$_SYS_TIME_MODEL TM2 ,SNAP_RANGES SR WHERE TM1.DBID = SR.DBID AND TM1.INSTANC
E_NUMBER = SR.INSTANCE_NUMBER AND TM1.SNAP_ID = SR.MIN_SNAP AND TM1.STAT_ID = SR
.STAT_ID AND TM2.DBID = SR.DBID AND TM2.INSTANCE_NUMBER = SR.INSTANCE_NUMBER AND
 TM2.SNAP_ID = SR.MAX_SNAP AND TM2.STAT_ID = SR.STAT_ID ) SELECT STAT_NAME ,ROUN
D(SUM(DELTA_TIME/1000000),2) AS SECS FROM DELTA_DATA GROUP BY STAT_NAME

SQL执行计划为:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
set lines 1000 pages 1000
select * from table(dbms_xplan.display_awr('auyf8px9ywc6j'));

Plan hash value: 295135324

-------------------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                                  | Name                   | Rows  | Bytes | Cost (%CPU)| Time     | Pstart| Pstop |
-------------------------------------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                           |                        |       |       |    13 (100)|          |       |       |
|   1 |  HASH GROUP BY                             |                        |     1 |    87 |    13   (8)| 00:00:01 |       |       |
|   2 |   VIEW                                     | VM_NWVW_1              |     1 |    87 |    13   (8)| 00:00:01 |       |       |
|   3 |    FILTER                                  |                        |       |       |            |          |       |       |
|   4 |     HASH GROUP BY                          |                        |     1 |   247 |    13   (8)| 00:00:01 |       |       |
|   5 |      HASH JOIN                             |                        |     1 |   247 |    12   (0)| 00:00:01 |       |       |
|   6 |       NESTED LOOPS                         |                        |     1 |   204 |     7   (0)| 00:00:01 |       |       |
|   7 |        NESTED LOOPS                        |                        |     1 |   204 |     7   (0)| 00:00:01 |       |       |
|   8 |         NESTED LOOPS                       |                        |     1 |   127 |     7   (0)| 00:00:01 |       |       |
|   9 |          TABLE ACCESS FULL                 | WRM$_SNAPSHOT          |     1 |    50 |     7   (0)| 00:00:01 |       |       |
|  10 |          PARTITION RANGE ITERATOR          |                        |     1 |    77 |     0   (0)|          |   KEY |   KEY |
|  11 |           TABLE ACCESS BY LOCAL INDEX ROWID| WRH$_SYS_TIME_MODEL    |     1 |    77 |     0   (0)|          |   KEY |   KEY |
|  12 |            INDEX RANGE SCAN                | WRH$_SYS_TIME_MODEL_PK |     1 |       |     0   (0)|          |   KEY |   KEY |
|  13 |         PARTITION RANGE ITERATOR           |                        |     1 |       |     0   (0)|          |   KEY |   KEY |
|  14 |          INDEX RANGE SCAN                  | WRH$_SYS_TIME_MODEL_PK |     1 |       |     0   (0)|          |   KEY |   KEY |
|  15 |        TABLE ACCESS BY LOCAL INDEX ROWID   | WRH$_SYS_TIME_MODEL    |     1 |    77 |     0   (0)|          |     1 |     1 |
|  16 |       TABLE ACCESS FULL                    | WRH$_STAT_NAME         |     2 |    86 |     5   (0)| 00:00:01 |       |       |
-------------------------------------------------------------------------------------------------------------------------------------


45 rows selected.

如果进一步获取SQL的awr报告还可以看到SQL执行的统计信息:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
Stat Name   Statement Total Per Execution   % Snap Total
Elapsed Time (ms)   582,925 582,924.68  1.84
CPU Time (ms)   64,811  64,811.15   5.89
Executions  1        
Buffer Gets 2,472,595   2,472,595.00    8.88
Disk Reads  1   1.00    0.00
Parse Calls 1   1.00    0.00
Rows    0   0.00     
User I/O Wait Time (ms) 65,348       
Cluster Wait Time (ms)  17       
Application Wait Time (ms)  0        
Concurrency Wait Time (ms)  1        
Invalidations   0        
Version Count   1        
Sharable Mem(KB)    64       

查到这里其实已经确认这个事情并不是人为,因为如果拿这个SQL_ID去网络搜索,会发现有人提到过这个SQL_ID,说这是由MMON发起的SQL

It looks like something made by a DBA, but it comes from the MMON.

因为只是临时文件,且目前没有被持续使用到,又是测试环境,可以直接按照测试需求resize为较小值,然后为避免这样的事情,再关闭其自动扩展的功能:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
sys@DEMO> alter database tempfile 1 resize 500M;
sys@DEMO> alter database tempfile 1 autoextend off;

修改完再次查询:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
sys@DEMO> select file_id, file_name, tablespace_name, bytes/1048576 "MB" from dba_temp_files;

   FILE_ID FILE_NAME                                               TABLESPACE_NAME                        MB
---------- ------------------------------------------------------- ------------------------------ ----------
         1 +DATA/demo/tempfile/temp.264.1018829761                 TEMP                                  500
         2 +DATA/demo/tempfile/temp_jingyu.258.1018830415          TEMP_JINGYU                            30

DG备库启动应用,观察确认恢复正常同步:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
sys@ORCL> recover managed standby database using current logfile disconnect;
Media recovery complete.

sys@ORCL> select * from v$dataguard_stats;

NAME                             VALUE                          UNIT                           TIME_COMPUTED                  DATUM_TIME
-------------------------------- ------------------------------ ------------------------------ ------------------------------ ------------------------------
transport lag                    +00 00:00:00                   day(2) to second(0) interval   11/18/2019 23:10:55            11/18/2019 23:10:54
apply lag                        +00 00:00:00                   day(2) to second(0) interval   11/18/2019 23:10:55            11/18/2019 23:10:54
apply finish time                +00 00:00:00.000               day(2) to second(3) interval   11/18/2019 23:10:55
estimated startup time           24                             second                         11/18/2019 23:10:55

一般确认时间正确,各指标的value都为0即可。若不放心可以再手工去主库切换几次日志,看下备库的同步表现。

本文参与 腾讯云自媒体同步曝光计划,分享自作者个人站点/博客。
原始发表:2019-11-18 ,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 作者个人站点/博客 前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
Oracle性能调查之ASH(二)
本文作者系Scott(中文名陈晓辉),现任大连华信资深分析师 ,ORACLE数据库专家,曾就职于甲骨文中国。个人主页:segmentfault.com/u/db_perf ,经其本人授权发布。
SQLplusDB
2022/08/19
4180
Oracle性能调查之ASH(二)
Oracle查询表空间或数据库的增长量
查看数据库历史增长情况 此处是通过计算数据库所有表空间的历史增长情况来计算数据库历史情况。
AiDBA宝典
2023/04/27
1.1K0
Oracle查询表空间或数据库的增长量
运维,诊断,健康检查,优化定制工具ora使用说明
使用工具的目的是为了提高工作效率, 先有思路和方法,然后再借助工具,方能达到事半功倍的效果.
老虎刘
2022/06/27
1.4K0
使用shell脚本查看数据库负载情况(第二篇)(r3笔记第92天)
在之前写了一个shell脚本,能够得到一个基于时间点的数据库负载报告。 使用shell脚本查看数据库负载情况 http://blog.itpub.net/23718752/viewspace-1168027/ 在生产环境中快照的生成频率可能10分钟或者半个小时就会生成,频率要快些,使用原先的脚本执行起来会有一定的延时。 想查看在快照的时间间隔内数据库的负载情况。这样能够更高效的定位某个问题。比如10点到11点,每10分钟生成一次快照。可能问题发生在10:40~10:50,如果通过一个小时的快照就不一定能够
jeanron100
2018/03/15
6910
记录一则enq: TX - row lock contention的分析过程
故障描述:与客户沟通,初步确认故障范围大概是在上午的8:30-10:30之间,反应故障现象是Tomcat的连接数满导致应用无法连接,数据库alert中无明显报错,需要协助排查原因。 1.导入包含故障时刻的数据 2.创建m_ash表,明确故障时刻 3.确定异常时刻的top n event 4.确定最终的top holder 5.总结 6.reference 1.导入包含故障时刻的数据 为了便于后续分析,我向客户索要了从昨天下午13:00到今天18:00的awrdump,导入到自己的实验环境进行分析。 生产环境
Alfred Zhao
2018/05/11
1.6K0
如何通过 dba_hist_active_sess_history 分析数据库历史性能问题
如何通过 dba_hist_active_sess_history 分析数据库历史性能问题背景在很多情况下,当数据库发生性能问题的时候,我们并没有机会来收集足够的诊断信息,比如system state dump或者hang analyze,甚至问题发生的时候DBA根本不在场。这给我们诊断问题带来很大的困难。那么在这种情况下,我们是否能在事后收集一些信息来分析问题的原因呢?在Oracle 10G或者更高版本上,答案是肯定的。本文我们将介绍一种通过dba_hist_active_sess_history的数据来
lemotree
2022/06/21
2.4K1
资源下载丨Oracle优化工程师常用的34个脚本
墨墨导读:本文分享Oracle驻场工程师常用的脚本,基本上包含了日常监控、维护、故障定位及处理、SQL性能优化大部分场景,有了这些脚本会让你的工作变得更轻松,文末附下载链接。
数据和云
2021/03/09
7090
一线运维 DBA 五年经验常用 SQL 大全(二)
本文 SQL 及相关命令均是在运维工作中总结整理而成的,对于运维 DBA 来说可提高很大的工作效率,值得收藏。当然如果你全部能够背下来那就很牛逼了,如果不能,还是建议收藏下来慢慢看,每条 SQL 的使用频率都很高,肯定能够帮助到你。
JiekeXu之路
2021/03/15
8660
一线运维 DBA 五年经验常用 SQL 大全(二)
Oracle DBA的SQL编写技能提升宝典(含SQL资源)
背景:要迁移数据库,需要创建与源库相同的表空间,大小与源库相同。由于个别表空间较大,手工添加可能需要写很多的脚本,于是同事通过PL/SQL解决了问题。
数据和云
2021/10/13
1.1K0
Oracle DBA的SQL编写技能提升宝典(含SQL资源)
####### Scripts Summary #######
Scripts Summary Version: 1.0.1 issueDate: 2017-11-11 modifiedDate: 2017-11-28
Alfred Zhao
2019/05/24
5590
一线运维 DBA 五年经验常用 SQL 大全(三)
本文作为常用 SQL 系列的第三篇,本文涉及到的 SQL 及相关命令均是在运维工作中总结整理而成的,对于运维 DBA 来说可提高很大的工作效率,值得收藏下来慢慢看。
JiekeXu之路
2023/02/24
1.3K0
一线运维 DBA 五年经验常用 SQL 大全(三)
案例解读:利用12c渐进式DASH分析"ON CPU"
墨墨导读:本文来自墨天轮读者“Anbob”供稿,分享利用12c渐进式DASH分析"ON CPU"的过程。
数据和云
2021/03/11
5590
一线运维 DBA 五年经验常用 SQL 大全(一)
本文 SQL 均是在运维工作中总结整理而成的,对于运维 DBA 来说可提高很大工作效率,当然如果你全部能够背下来那就牛逼了,如果不能,建议收藏下来慢慢看,每条 SQL 的使用频率都很高,肯定能够帮助到你。
JiekeXu之路
2021/02/23
1.4K0
探究AWR 第一篇
statspack相比awr算是比较通用,而且免费,可以在标准版,企业版中使用,awr是新企业版本中才有的,算是statspack的一个升级版,而且代码不公开。但是实现的功能和数据的采集要更丰富。 awr算是dba工作的必备工具。自己总结了一下,大概由以下几个方面来说明一下。 1.snapshot的管理 2.基线的管理 3.所需空间开销和设置 4.awr数据的迁移 5.生成awr相关的报告 6.awr相关的视图和基表 1.snapshot的管理 先来看看snapshot,这是列出近几天的snapshot
jeanron100
2018/03/13
6980
DBA命令速查6: 临时表空间( Temporary Tablespace)的相关确认SQL
编者按:留存一下供自己需要时查找。 【免责声明】本号文章仅代表个人观点,与任何公司无关,仅供参考。 编辑|SQL和数据库技术(ID:SQLplusDB) 临时表空间表空间信息 select * from dba_temp_free_space; 临时表空间的使用量 SELECT d.tablespace_name "Name" , NVL(a.bytes / 1024 / 1024, 0) "Size(MB)", NVL(t.bytes, 0) / 1024 / 1024 "U
SQLplusDB
2022/08/22
7080
PLSQL_查询SQL的执行次数和频率(案例)
在ORACLE数据库应用调优中,一个SQL的执行次数/频率也是常常需要关注的,因为某个SQL执行太频繁,要么是由于应用设计有缺陷,需要在业务逻辑上做出优化处理,要么是业务特殊性所导致。
全栈程序员站长
2022/07/05
1.3K0
Oraccle SQL调优系列之ASH简介
我写的SQL调优专栏:https://blog.csdn.net/u014427391/article/category/8679315
SmileNicky
2022/05/07
1.1K0
Oraccle SQL调优系列之ASH简介
DBA常用SQL语句(6)- ​日常管理
由于 v$active_session_history 和 dba_hist_active_sess_history 的数据来源于 awr 和 ash 采样,记录并不完全,故查询结果并不准确。
Yunjie Ge
2022/04/23
5410
Oracle基础教程之AWR固定基线
前言:可以创建AWR基线来为数据库建立已保存的工作负载视图,以便以后用来与其他AWR快照进行比较。
星哥玩云
2022/08/16
3490
ORACLE常用性能监控SQL【二】
条件为什么block>100,因为一些很小的表,只有几行数据实际大小很小,但是block一次性分配就是5个(11g开始默认一次性分配1M的block大小了,见create table storged的NEXT参数),5个block相对于几行小表数据来说就相差太大了
小小工匠
2021/08/16
4K0
相关推荐
Oracle性能调查之ASH(二)
更多 >
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档