详细解读 STATSPACK 报告
- 格式:doc
- 大小:300.00 KB
- 文档页数:66
数据库系统远程性能监测报告模版文档控制修改记录审阅分发目录文档控制i概述1数据库配置1非缺省的数据库参数:1 Sga 占用情况3数据文件使用情况4表空间管理方式和碎片17 Tablespaces Free Space17排序区的使用情况:18回滚段:Rollback Segments19使用system 表空间的表和索引21表的数据行迁移情况21 Users错误!未定义书签。
日志切换检查21 Errors Check22系统空间使用情况:错误!未定义书签。
系统和数据库的性能22操作系统性能监视22数据库配置和监控(statspack报告摘录) 22运行优势26需改进的方面:26本次检查已经解决的问题:26建议27应立即解决的问题27将来应解决的问题27介绍在此次的ORACLE专家服务中我们完成了对呼和浩特计费系统(服务器位于:呼和浩特网通机房)的健康检查,在这次检查中我们发现了一些与数据库相关的的一些潜在的问题,同时我们对计费系统也有了更深入的了解,我们将根据所搜集的信息得出下面的报告。
在此,我们感谢呼和浩特网通及内蒙网通公司对此次系统检查所给予的积极的支持和配合!读者此系统健康检查报告供下列读者使用:概述此次数据库健康检查主….数据库,下几个方面:数据库配置,数据库可用性及性能,我们观察到该系统在数据库的参数以及存储方面的设置或配置尚好,同时也发现了一些潜在的问题,在下面的建议部分,我们将提出相关的改进措施。
数据库配置非缺省的数据库参数:使用的参数文件:pfile节点1:End valueParameter Name Begin value (if different)----------------------------- --------------------------------- --------------_lm_direct_sends lkmgr_sqlexec_progression_cost 0background_dump_dest /o8i/app/oracle/admin/hhlbas/bdumcompatible 8.1.0control_files /dev/vgora/rcontrol1, /dev/vgora/core_dump_dest /o8i/app/oracle/admin/hhlbas/cdumdb_block_buffers 25600db_block_lru_latches 2db_block_size 8192db_file_multiblock_read_count 4db_name hhlbasdb_writer_processes 2disk_asynch_io FALSEdml_locks 100000ifile /o8i/app/oracle/admin/hhlbas/pfil instance_name hhlbasjava_pool_size 32768job_queue_interval 30job_queue_processes 5large_pool_size 614400lm_locks 200000, 200000lm_ress 100000, 100000log_archive_dest /arch2/log_archive_format arch_%t_%s.arclog_archive_start TRUElog_buffer 67108864log_checkpoint_interval 100000log_checkpoint_timeout 0max_enabled_roles 30open_cursors 1500os_authent_prefixparallel_automatic_tuning TRUEparallel_server TRUEprocesses 300remote_login_passwordfile EXCLUSIVErollback_segments rbs2_1, rbs2_2, rbs2_3, rbs2_4, rservice_namessession_cached_cursors 50shared_pool_size 157286400sort_area_retained_size 655360sort_area_size 655360thread 2timed_statistics TRUEtransactions_per_rollback_seg 8user_dump_dest /o8i/app/oracle/admin/hhlbas/udum节点2同1建议:disk_asynch_io 改为truelog_buffer 改成3Mdb_file_multiblock_read_count 改成8gc_files_to_locks 设成1,8-25,27-30,32-79,81,83-141=2000each Sga 占用情况SQL> select * from v$sgastat;Total System Global Area 599955944 bytesFixed Size 104936 bytesVariable Size 323018752 bytesDatabase Buffers 209715200 bytesRedo Buffers 67117056 bytesPOOL NAME BYTES----------- -------------------------- ----------fixed_sga 104936db_block_buffers 209715200log_buffer 67108864shared pool free memory 33097768shared pool miscellaneous 4358952shared pool dlm shared memory 18941486shared pool processes 348000shared pool gc_* 3584000shared pool fixed allocation callback 2072shared pool view columns d 488shared pool PLS non-lib hp 2136POOL NAME BYTES----------- -------------------------- ----------shared pool KGK heap 13624shared pool trigger inform 12248shared pool dlm process array 274512shared pool KGFF heap 102576shared pool sessions 814720shared pool State objects 101752448shared pool db_block_buffers 6144000shared pool db_block_hash_buckets 1024048shared pool enqueue_resources 10422880shared pool log_buffer 1572864shared pool KQLS heap 4107280POOL NAME BYTES----------- -------------------------- ----------shared pool dictionary cache 5293096shared pool errors 6544shared pool PL/SQL DIANA 1529528shared pool table columns 30656shared pool library cache 55839696shared pool PX subheap 66032shared pool sql area 25481496shared pool table definiti 2584shared pool PL/SQL MPCODE 29000944shared pool transactions 559360shared pool DML locks 16800000POOL NAME BYTES----------- -------------------------- ----------shared pool event statistics per sess 1163120large pool free memory 299976large pool PX msg pool 314424java pool free memory 32768建议:数据文件使用情况column file_id format 99999column file_name format a25column bytes format 9999999999column status format a10column autoextensible format a10Select file_id,file_name,bytes,status,autoextensible from dba_data_files;TABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- -----------STATUS AUTOEXTENS---------- ----------SYSTEM 1 /dev/vgora/rsystem 1048576000AVAILABLE NOTOOLS 2 /dev/vgora/rtools208666624AVAILABLE NORBS 3 /dev/vgora/rrollback1 2095054848AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------TEMP 4 /dev/vgora/rtemp 1047527424AVAILABLE NOUSERS 5 /dev/vgora/rusers313524224AVAILABLE NORBS 6 /dev/vgora/rrollback2 2095054848AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------RBS 7 /dev/vgora/rrollback3 2095054848AVAILABLE NOBILLDATA2 8 /dev/vgora/rapp01 2095054848 AVAILABLE NOBILLDATA1 9 /dev/vgora/rapp11 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA2 10 /dev/vgora/rapp02 2095054848 AVAILABLE NOBILLDATA2 11 /dev/vgora/rapp03 2095054848 AVAILABLE NOBILLDATA2 12 /dev/vgora/rapp04 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS-------- ----------BILLDATA2 13 /dev/vgora/rapp05 2095054848 AVAILABLE NOBILLDATA2 14 /dev/vgora/rapp06 2095054848 AVAILABLE NOBILLDATA2 15 /dev/vgora/rapp07 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA2 16 /dev/vgora/rapp08 2095054848 AVAILABLE NOBILLDATA2 17 /dev/vgora/rapp09 2095054848 AVAILABLE NOBILLDATA2 18 /dev/vgora/rapp10 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA1 19 /dev/vgora/rapp12 2095054848 AVAILABLE NOBILLDATA1 20 /dev/vgora/rapp13 2095054848 AVAILABLE NOBILLDATA1 21 /dev/vgora/rapp14 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA1 22 /dev/vgora/rapp15 2095054848 AVAILABLE NOBILLDATA2 23 /dev/vgora/rapp16 2095054848 AVAILABLE NOBILLDATA2 24 /dev/vgora/rapp17 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA2 25 /dev/vgora/rapp18 2095054848 AVAILABLE NOBILLTEMP 26 /dev/vgora/rapp28 2095054848 AVAILABLE NOBILLDATA2 27 /dev/vgora/rapp19 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA2 28 /dev/vgora/rapp20 2095054848 AVAILABLE NOBILLINDEX1 29 /dev/vgora/rapp21 2095054848 AVAILABLE NOBILLINDEX1 30 /dev/vgora/rapp22 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLTEMP 31 /dev/vgora/rapp31 2095054848 AVAILABLE NOBILLINDEX1 32 /dev/vgora/rapp23 2095054848 AVAILABLE NOBILLINDEX1 33 /dev/vgora/rapp24 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 34 /dev/vgora/rapp25 2095054848 AVAILABLE NOBILLDATA1 35 /dev/vgora/rapp26 2095054848AVAILABLE NOBILLDATA1 36 /dev/vgora/rapp27 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 37 /dev/vgora/rapp29 2095054848 AVAILABLE NOBILLINDEX1 38 /dev/vgora/rapp30 2095054848 AVAILABLE NOBILLDATA0 39 /dev/vgora/rapp32 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA0 40 /dev/vgora/rapp33 2095054848 AVAILABLE NOBILLDATA0 41 /dev/vgora/rapp34 2095054848 AVAILABLE NOBILLDATA0 42 /dev/vgora/rapp35 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA0 43 /dev/vgora/rapp36 2095054848 AVAILABLE NOBILLDATA1 44 /dev/vgora/rapp37 2095054848 AVAILABLE NOBILLDATA1 45 /dev/vgora/rapp38 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX 46 /dev/vgora/rapp39 2095054848BILLINDEX 47 /dev/vgora/rapp40 2095054848 AVAILABLE NOBILLINDEX 48 /dev/vgora/rapp41 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA 49 /dev/vgora/rapp42 2095054848 AVAILABLE NOBILLDATA0 50 /dev/vgora/rapp43 2095054848 AVAILABLE NOBILLDATA0 51 /dev/vgora/rapp44 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA0 52 /dev/vgora/rapp45 2095054848 AVAILABLE NOBILLDATA0 53 /dev/vgora/rapp46 2095054848 AVAILABLE NOBILLDATA0 54 /dev/vgora/rapp47 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA0 55 /dev/vgora/rapp48 2095054848 AVAILABLE NOBILLDATA1 56 /dev/vgora/rapp49 2095054848 AVAILABLE NOBILLDATA0 57 /dev/vgora/rapp50 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA0 59 /dev/vgora/rapp52 2095054848 AVAILABLE NOBILLDATA3 60 /dev/vgora/rapp57 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA3 61 /dev/vgora/rapp53 2095054848 AVAILABLE NOBILLDATA3 62 /dev/vgora/rapp54 2095054848 AVAILABLE NOBILLTEMP 63 /dev/vgora/rapp56 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA3 64 /dev/vgora/rapp55 2095054848 AVAILABLE NOBILLDATA3 65 /dev/vgora/rapp58 2095054848 AVAILABLE NOBILLDATA3 66 /dev/vgora/rapp59 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA0 67 /dev/vgora/rapp60 2095054848 AVAILABLE NOBILLDATA3 68 /dev/vgora/rapp61 2095054848 AVAILABLE NOBILLDATA3 69 /dev/vgora/rapp62 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENSAVAILABLE NOBILLINDEX3 71 /dev/vgora/rapp64 2095054848 AVAILABLE NOBILLINDEX3 72 /dev/vgora/rapp65 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX 73 /dev/vgora/rapp66 2095054848 AVAILABLE NOBILLINDEX 74 /dev/vgora/rapp67 2095054848 AVAILABLE NOBILLDATA 75 /dev/vgora/rapp68 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX 76 /dev/vgora/rapp69 2095054848 AVAILABLE NOBILLDATA4 77 /dev/vgora/rapp70 2095054848 AVAILABLE NOBILLDATA4 78 /dev/vgora/rapp71 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA4 79 /dev/vgora/rapp72 2095054848 AVAILABLE NOBILLTEMP 80 /dev/vgora/rapp73 2095054848 AVAILABLE NOINTERFACE_KFXT 81 /dev/vgora/rapp76 2095054848AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES---------- ----------RBS 82 /dev/vgora/rapp75 2092957696AVAILABLE NOBILLINDEX1 83 /dev/vgora/rapp77 2095054848 AVAILABLE NOBILLINDEX 84 /dev/vgora/rapp78 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA1 85 /dev/vgora/rapp79 2095054848 AVAILABLE NOBILLINDEX1 86 /dev/vgora/rapp80 2095054848 AVAILABLE NOBILLINDEX1 87 /dev/vgora/rapp81 2095054848 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA 88 /dev/vgora/rapp82 2092957696 AVAILABLE NOBILLDATA1 89 /dev/vgora/rapp85 2092957696 AVAILABLE NOBILLINDEX 90 /dev/vgora/rapp83 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 91 /dev/vgora/rapp84 2092957696 AVAILABLE NOBILLDATA 92 /dev/vgora/rapp86 2092957696 AVAILABLE NOBILLDATA1 93 /dev/vgora/rapp87 2092957696 AVAILABLE NO------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 94 /dev/vgora/rapp88 2092957696 AVAILABLE NOBILLDATA4 95 /dev/vgora/rapp89 2092957696 AVAILABLE NOBILLTEMP 96 /dev/vgora/rapp90 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 97 /dev/vgora/rapp91 2092957696 AVAILABLE NOBILLDATA 98 /dev/vgora/rapp92 2092957696 AVAILABLE NOBILLDATA1 99 /dev/vgora/rapp93 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA3 100 /dev/vgora/rapp94 2092957696 AVAILABLE NOBILLINDEX 101 /dev/vgora/rapp95 2092957696 AVAILABLE NOBILLINDEX1 102 /dev/vgora/rapp96 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 103 /dev/vgora/rapp97 2092957696 AVAILABLE NOBILLDATA4 104 /dev/vgora/rapp98 2092957696 AVAILABLE NOBILLINDEX1 105 /dev/vgora/rapp99 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX 106 /dev/vgora/rapp100 2092957696 AVAILABLE NOBILLDATA0 107 /dev/vgora/rapp101 2092957696 AVAILABLE NOBILLDATA1 108 /dev/vgora/rapp102 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX 109 /dev/vgora/rapp103 2092957696 AVAILABLE NOBILLINDEX3 110 /dev/vgora/rapp104 2092957696 AVAILABLE NOBILLDATA3 111 /dev/vgora/rapp105 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA3 112 /dev/vgora/rapp106 2092957696 AVAILABLE NOBILLDATA3 113 /dev/vgora/rapp107 2092957696 AVAILABLE NOBILLDATA3 114 /dev/vgora/rapp108 2092957696 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA3 115 /dev/vgora/rapp109 2092957696 AVAILABLE NOBILLDATA3 116 /dev/vgora/rapp110 2092957696 AVAILABLE NOBILLINDEX 117 /dev/vgora/rapp111 2092957696TABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA0 118 /dev/vgora/rapp112 2092957696 AVAILABLE NOBILLINDEX1 119 /dev/vgora/rapp113 2092957696 AVAILABLE NOBILLINDEX1 120 /dev/vgora/rapp114 2097152000 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 121 /dev/vgora/rapp115 2097152000 AVAILABLE NOBILLDATA1 122 /dev/vgora/rapp116 2097152000 AVAILABLE NOBILLDATA0 123 /dev/vgora/rapp117 2097152000 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA1 124 /dev/vgora/rapp118 2097152000 AVAILABLE NOBILLDATA2 125 /dev/vgora/rapp119 2097152000 AVAILABLE NOBILLDATA0 126 /dev/vgora/rapp120 2097152000 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA4 127 /dev/vgora/rapp121 2097152000 AVAILABLE NOBILLDATA 128 /dev/vgora/rapp122 2097152000 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA 130 /dev/vgora/rapp124 2097152000 AVAILABLE NOBILLDATA 131 /dev/vgora/rapp125 2097152000 AVAILABLE NOBILLDATA1 132 /dev/vgora/rapp126 2097152000 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLINDEX1 133 /dev/vgora/rapp127 2097152000 AVAILABLE NOBILLINDEX1 134 /dev/vgora/rapp128 2139095040 AVAILABLE NOBILLDATA4 135 /dev/vgora/rapp129 2139095040 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA 136 /dev/vgora/rapp130 2139095040 AVAILABLE NOBILLINDEX1 137 /dev/vgora/rapp131 2139095040 AVAILABLE NOBILLDATA4 138 /dev/vgora/rapp132 2139095040 AVAILABLE NOTABLESPACE_NAME FILE_ID FILE_NAME BYTES------------------------------ ------- ------------------------- ----------- STATUS AUTOEXTENS---------- ----------BILLDATA1 139 /dev/vgora/rapp133 2139095040 AVAILABLE NOBILLDATA4 140 /dev/vgora/rapp134 2139095040 AVAILABLE NOAVAILABLE NOselect tablespace_name,file_id,file_name,bytes,status,autoextensible fromdba_temp_files order by file_id;无建议:无表空间管理方式和碎片表空间管理方式:select tablespace_name,extent_management from dba_tablespaces;TABLESPACE_NAME EXTENT_MAN------------------------------ ----------SYSTEM DICTIONARYTOOLS DICTIONARYRBS DICTIONARYTEMP DICTIONARYUSERS DICTIONARYBILLDATA DICTIONARYBILLINDEX DICTIONARYBILLTEMP DICTIONARYBILLDATA1 LOCALINTERFACE_KFXT DICTIONARYBILLDATA4 LOCALTABLESPACE_NAME EXTENT_MAN------------------------------ ----------BILLDATA3 LOCALBILLDATA2 LOCALBILLINDEX1 LOCALBILLINDEX3 LOCALBILLDATA0 DICTIONARY建议除了system和RBS外都改成本地管理。
samtools stats结果解读题目:解读Samtools stats 结果导言:Samtools 是一个强大的工具,用于对测序数据进行分析和处理。
其中,Samtools stats 是一个常用的功能,用于统计BAM 或SAM 格式文件的各种统计数据。
本文将详细介绍Samtools stats 的结果解读及其在测序数据分析中的应用。
一、Samtools stats 方法及原理1.1 Samtools 简介Samtools 是一个处理和分析比对文件的工具集,包括了许多常用的功能,如格式转换、质量控制、序列比对和数据统计等。
1.2 Samtools stats 的作用Samtools stats 可以对BAM 或SAM 格式的比对文件进行全面的统计分析,并生成统计结果。
通过分析比对文件的各种统计数据,我们可以深入了解测序数据的质量和性能,并为后续的分析和解读提供基础。
1.3 "samtools stats" 命令的使用可以使用以下命令运行Samtools stats:bashsamtools stats <input.bam> > <output.stats>其中,`<input.bam>` 是输入的比对文件(BAM 格式),`<output.stats>` 是输出的统计结果文件。
1.4 Samtools stats 的原理Samtools stats 分析比对文件的每一条比对记录,并将各种统计信息聚合在一起。
它会生成两个类型的输出文件:总的统计结果文件和染色体级别的统计结果文件。
总的统计结果文件包含了关于比对数据集中每一条比对记录的总体统计信息,而染色体级别的统计结果文件则记录了每个染色体或参考序列的统计信息。
二、Samtools stats 的结果解读2.1 总的统计信息总的统计信息提供了比对文件中各种统计数据的总体概述。
1.第一部分:数据库概要信息开头是数据库概要信息。
(1)首先是数据库名称、dbid等信息:Database DB Id Instance Inst Num Startup Time Release RAC ~~~~~~~~ ----------- ------------ -------- --------------- ----------- --- 1808102524 fantlam 1 27-Sep-11 23:46 10.2.0.1.0 NOHost Name: localhost.locald Num CPUs: 1 Phys Memory(MB): 0~~~~(2)接下来是数据库采样时段信息,记录了数据库采样的时间,以及采样点数,这部分信息对report来说十分重要。
Snapshot Snap Id Snap Time Sessions Curs/Sess Comment~~~~~~~~ ---------- ------------------ -------- --------- ------------------- Begin Snap: 11 28-Sep-11 01:01:04 17 4.9End Snap: 21 28-Sep-11 01:49:01 16 6.8Elapsed: 47.95 (mins)(3)Cache信息,列举了数据库的内存分配信息,从Oracle9i开始,主要SGA参数可以进行动态调整,所以此处的Cache信息来自采样结束时刻:Cache Sizes Begin End~~~~~~~~~~~ ---------- ----------Buffer Cache: 92M 96M Std Block Size: 8K Shared Pool Size: 56M 52M Log Buffer: 2,859K2.第二部分:负载概要信息接下来报表输出的是数据库的负载概要信息,这些信息分别通过每秒和每事务形式展现。
库容CPK分析报告1. 引言库容CPK分析是一种统计方法,用于评估一个过程的稳定性和能力。
它是根据数据的离散程度和过程规格限制来计算的,以确定过程是否能够满足规格要求。
本报告将对所提供的数据进行库容CPK分析,以评估过程的稳定性和能力。
2. 数据收集为了进行库容CPK分析,我们收集了一段时间内某个过程的数据。
这些数据包括过程的输出值,以及与过程相关的规格上限和下限。
下表是我们收集到的样本数据的示例:样本编号过程输出值1 4.522 4.583 4.554 4.535 4.51……3. 数据分析3.1 数据描述统计首先,我们对收集到的数据进行描述统计分析,以了解数据的分布情况和基本统计特征。
下面是对样本数据进行的描述统计分析:•样本数量:样本数量为100个。
•平均值:样本数据的平均值为4.54。
•标准差:样本数据的标准差为0.03。
•最小值:样本数据的最小值为4.48。
•最大值:样本数据的最大值为4.60。
3.2 数据分布图为了更直观地了解数据的分布情况,我们绘制了样本数据的直方图和箱线图。
下图展示了直方图和箱线图的结果:HistogramHistogramBoxplotBoxplot3.3 过程能力指数计算库容CPK分析的核心是计算过程的能力指数。
过程能力指数包括过程能力指数上限(CPK上限)和过程能力指数下限(CPK下限),用于评估过程的能力是否满足规格要求。
过程能力指数的计算公式如下:CPK上限 = (规格上限 - 平均值) / (3 * 标准差)CPK下限 = (平均值 - 规格下限) / (3 * 标准差)根据样本数据的分析结果,我们计算出过程能力指数的值如下:CPK上限 = (4.60 - 4.54) / (3 * 0.03) = 0.67CPK下限 = (4.54 - 4.48) / (3 * 0.03) = 0.673.4 过程能力评估根据过程能力指数的计算结果,我们可以对过程的能力进行评估。
statspack报告的分析调整STATSPACK 的收集门限Statspack 有两种类型的收集选项:级别(level):控制收集数据的类型门限(threshold):设置收集的数据的阈值。
1.级别(level)Statspack 共有三种快照级别,默认值是5a.level 0: 一般性能统计。
包括等待事件、系统事件、系统统计、回滚段统计、行缓存、SGA、会话、锁、缓冲池统计等等。
b.level 5: 增加SQL 语句。
除了包括level0 的所有内容,还包括SQL 语句的收集,收集结果记录在stats$sql_summary 中。
c.level 10: 增加子锁存统计。
包括level5 的所有内容。
并且还会将附加的子锁存存入stats$lathc_children 中。
在使用这个级别时需要慎重,建议在Oracle support 的指导下进行。
可以通过statspack 包修改缺省的级别设置SQL>execute statspack.snap(i_snap_level=>0,i_modify_parameter=>’true’);通过这样的设置,以后的收集级别都将是0 级。
如果你只是想本次改变收集级别,可以忽略i_modify_parameter 参数。
SQL>execute statspack.snap(i_snap_level=>10);2.快照门限快照门限只应用于stats$sql_summary 表中获取的SQL 语句。
因为每一个快照都会收集很多数据,每一行都代表获取快照时数据库中的一个SQL 语句,所以stats$sql_summary 很快就会成为Statspack 中最大的表。
门限存储在stats$statspack_parameter 表中。
让我们了结一下各种门限:a. executions_th 这是SQL 语句执行的数量(默认值是100)b. disk_reads_tn 这是SQL 语句执行的磁盘读入数量(默认值是1000)c. parse_calls_th 这是SQL 语句执行的解析调用的数量(默认值是1000)d. buffer_gets_th 这是SQL 语句执行的缓冲区获取的数量(默认值是10000)任何一个门限值超过以上参数就会产生一条记录。
Statspack工具在Oracle项目中的应用目录1附录 (5)1.1附录1:S TATSPACK R EPORT模块解释 (5)1.1.1Head Information (5)1.1.1.1 原始算法 (5)1.1.1.2 关键字说明 (6)1.1.1.3 参数说明 (7)1.1.1.1.1 SESSION_CACHED_CURSORS (7)1.1.1.1.2 OPEN_CURSORS (7)1.1.2Cache Sizes (end) (7)1.1.2.1 原始算法 (8)1.1.2.2 关键字说明 (8)1.1.2.3 参数说明 (8)1.1.1.1.3 DB_CACHE_SIZE (8)1.1.1.1.4 DB_KEEP_CACHE_SIZE (9)1.1.1.1.5 DB_RECYCLE_CACHE_SIZE (9)1.1.1.1.6 DB_nK_CACHE_SIZE (9)1.1.1.1.7 DB_BLOCK_SIZE (9)1.1.1.1.8 SHARED_POOL_SIZE (10)1.1.1.1.9 LOG_BUFFER (10)1.1.3Load Profile (11)1.1.3.1 原始算法说明 (11)1.1.3.2 关键字说明 (14)1.1.1.1.10 Redo size (14)1.1.1.1.11 Logical reads (14)1.1.1.1.12 block changes (14)1.1.1.1.13 Physical reads (15)1.1.1.1.14 Physical writes (16)1.1.1.1.15 User calls (16)1.1.1.1.16 Parses (17)1.1.1.1.17 Hard parses (18)1.1.1.1.18 Sorts (20)1.1.1.1.19 Average Rows Per Sort (20)1.1.1.1.20 Logons (21)1.1.1.1.21 Executes (21)1.1.1.1.22 Transactions (21)1.1.1.1.23 Commits Per Second (21)1.1.1.1.24 Commit % (21)1.1.1.1.25 % Blocks changed per Read (22)1.1.1.1.26 Recursive Call % (22)1.1.1.1.27 Rollback per transaction % (22)1.1.1.1.28 Rows per Sort (23)1.1.3.3 参数说明 (24)1.1.4Instance Efficiency Percentages (24)1.1.4.1 原始算法说明 (25)1.1.4.2 关键字说明 (26)1.1.1.1.30 Buffer Nowait % (26)1.1.1.1.31 Redo NoWait % (26)1.1.1.1.32 Buffer Hit % (27)1.1.1.1.33 Buffer Cache Hit % (27)1.1.1.1.34 In-memory Sort % (28)1.1.1.1.35 Library Hit % (29)1.1.1.1.36 Data Dictionary Hit % (31)1.1.1.1.37 Data Dictionary Miss % (31)1.1.1.1.38 Soft Parse % (32)1.1.1.1.39 Execute to Parse % (33)1.1.1.1.40 Latch Hit % (34)1.1.1.1.41 Parse CPU to Parse Elapsd % (34)1.1.1.1.42 % Non-Parse CPU (34)1.1.5Shared Pool Statistics (34)1.1.5.1 原始算法说明 (34)1.1.5.2 关键字说明 (36)1.1.6SQL ordered by Gets (37)1.1.6.1 原始算法说明 (37)1.1.6.2 关键子字说明 (42)1.1.1.1.43 Buffer Gets (42)1.1.1.1.44 Executions (42)1.1.1.1.45 Gets per Exec (43)1.1.1.1.46 %Total (43)1.1.1.1.47 CPU Time (s) (43)1.1.1.1.48 Elapsd Time (s) (43)1.1.1.1.49 Hash V alue (43)1.1.7SQL ordered by Reads (43)1.1.7.1 原始算法说明 (44)1.1.7.2 关键字段说明 (45)1.1.8SQL ordered by Executions (46)1.1.8.1 原始算法说明 (46)1.1.8.2 关键字说明 (47)1.1.9SQL ordered by Parse Calls (48)1.1.9.1 原始算法说明 (48)1.1.9.2 关键字段说明 (49)1.1.10SQL ordered by Sharable Memory (49)1.1.10.1 原始算法说明 (50)1.1.10.2 关键字段说明 (51)1.1.11ordered by Version Count (52)1.1.11.1 原始算法说明 (52)1.2附录2:SQL优化测试方法 (53)1.2.1使用Statspack 测试SQL (53)1.2.2使用autotrace测试SQL (55)1.2.2.1 Set autotrace on (55)1.1.1.1.50 范例 (56)1.2.2.2 Set autotrace traceonly explain (63)1.2.3使用SQL_TRACE测试SQL (64)1.2.4使用Set Event测试SQL (64)1.3附录3:定制S TATSPACK R EPORT (65)1.3.1Report完整的SQL语句 (65)1.3.2Report更多的SQL语句 (65)1.3.3Report指定模块的SQL语句 (65)1.3.4Report指定字段的排序 (66)1.4附录4:AUTOTRACE STATISTICS字段说明 (67)1附录1.1附录1:Statspack Report模块解释1.1.1Head Information1.1.1.1 原始算法我们可通过如下语句直接从数据库获取更多的DB和instance信息:◆SELECTdbid,name,CREATEd,log_mode,checkpoint_change#,archive_change#,controlfile_created,contro lfile_change#FROM v$database;◆SELECTinstance_number,instance_name,host_name,version,startup_time,status,PARALLEL,archiver,dat abase_status FROM v$instance;也可直接从perfstat表查询:◆SELECT DISTINCTdbid "DB Id", instance_number "Inst Num", db_name "DB Name", instance_name "Instance", host_name "Host", version "Release",PARALLEL"Cluster"FROM stats$database_instance;整个statspack report报告一行记录。
(201-~201-学年第1学期)机械工程分析软件应用SIMPACK上级报告姓名:班级:学号:目录第一章、单摆模型 (1)第二章、双摆模型 (5)第三章、3连杆机构的建立 (8)第四章、转向架的建立 (12)第五章、车体的建模 (37)第一章、单摆模型1.1新建模型主菜单》,单击,新建一个名为mingchenPendulum 文件。
如图1-1。
图1-11.2 新建一个Body点开建模窗口》单击新建名为$B_mingchen_Body1的刚体双击【﹩B_mingchen_Body1】并设置参数如下:质量Mass=5.0kg质心(x,y,z)=(0,0,-0.3).转动惯量为Ixx=Iyy=10.0mkg.2.如图1-2.kg.2,Izz=1.0m单击【3D Geometry】并双击【$P_mingchen_Body_1_CUbody】设置模型的外形参数.并单击【OK】完成.如图1-3所示。
单击【save】保存设置。
图 1-2 模型参数图 1-3 外形设置1.3销钉的建立回到建模窗口》单击》双击【﹩B_mingchen_Body1】》【3DGeometry】新建一个实体【$P_mingchen_Body_1_Cubody_2】双击【$P_mingchen_Body_1_Cubody_2】设置模型参数如图1-4所示。
单击平【OK】返回建模窗口。
单击【save】保存设置。
图1-4 销钉参数1.4 铰的新建和体的铰接单击》双击$J_Body1》单击选择01号铰接并设置参数如图1-5所示,并铰接2个体,单击【OK】返回建模窗口完成铰的建立。
并保存设置。
图1-5 铰参数1.5运行并保存模型单击》单击【go】运行模型》单击【File】》save》【File】》Exit。
图 1-6 运行窗口图 1-7 模型第二章、双摆模型2.1模型的建立主菜单》,单击,新建名为 mingchen_dublePendulum 的文件,如图2-1所示。
2009年1月16日(最后更新:2009-02-07)评论发表评论本文共分两部分:1.压力测试方案2.压力测试报告该报告中使用的技术有loadrunner、nmon和statspack:1)loadrunner主要用来录制测试脚本,设置场景(包括虚拟用户数、操作循环次数、用户载入模式等设置),比较常用,不做单独讲述。
2)nmon用来分析OS性能,将在文章“OS性能分析之nmon工具”中讲述。
3)statspack用来分析DB性能,将在文章“DB性能分析之statspack工具”中讲述。
XXX项目压力测试方案作者: hand-sail.sun创建日期: 2008-12-23最后更新: 2008-12-29控制码:版本: 1.0目录文档控制 (2)概述 (4)综合压力测试 (5)统计负荷指标 (5)负荷及指标 (5)编制性能指标 (5)事务处理响应时间 (5)服务器性能信息 (5)脚本编写 (6)情景设置 (6)操作步骤 (6)月结压力测试 (8)统计负荷指标 (8)负荷指标 (8)编制性能指标 (8)事务处理响应时间 (8)服务器性能信息 (9)脚本编写 (9)情景设置 (9)操作步骤 (9)测试后期工作 (11)在TL-28007测试环境中进行测试,指定特定的负荷指标分别对审计失效、审计启用、TL系统月结请求运行、TL系统月结请求运行和审计同时开启这四种情况进行压力测试,然后对比分析测试结果,验证审计功能对系统性能的影响。
压力测试的环境如下:1)TL维护-28007 ORACLE版本信息:11.5.10.2应用层+9.2.0.5.0数据库2)应用服务器信息:10.195.36.11;IBM 9117-570;POWER5 1.9×4;15G内存;AIX 5.3;3) TL维护-28007 环境SGA信息:在综合压力测试中将按照测试环境的负荷进行测试,需要从测试结果中得到的有效信息主要是前台响应时间和CPU及磁盘IO等性能指标。
This section contains detailed guidance for evaluating each section of an AWR report. An AWR report is very similar to the STATSPACK report from Oracle9i, and it contains vital elapsed-time information on what happened during particular snapshot range. The data in an AWR or STATSPACK report is the delta, or changes, between the accumulated metrics within each snapshot.The main sections in an AWR report include:Report Summary: This gives an overall summary of the instance during the snapshot period, and it contains important aggregate summary information.(重要的聚集信息)Cache Sizes (end): This shows the size of each SGA region after AMM has changed them.(amm自动内存管理改变sga的各个区域后,每个sga区域的大小,该信息可与初始化参数中的原始值比较)This information can be compared to the original init.ora parameters at the end of the AWR report.Load Profile: This important section shows important rates expressed in units of per second and transactions per second.(系统负载)Instance Efficiency Percentages: With a target of 100%, these are high-level ratios for activity in the SGA.(实例(sga内存)效率)Shared Pool Statistics: This is a good summary of changes to the shared pool during the snapshot period.(快照期间共享池中,各种变化的概括)Top 5 Timed Events: This is the most important section in the AWR report. It shows the top wait events and can quickly show the overall database bottleneck.(快速的说明整个数据库瓶颈)Wait Events Statistics Section: This section shows a breakdown (分析、分类)of the main wait events in the database including foreground and background database wait events as well as time model, operating system, service, and wait classes statistics.Wait Events: This AWR report section provides more detailed wait event information for foreground user processes which includes Top 5 wait events and many other wait events that occurred during the snapshot interval.Background Wait Events: This section is relevant to the background process wait events.Time Model Statistics: Time mode statistics report how database-processing time is spent.(数据库处理时间如何消费的) This section contains detailed timing information on particular components participating in database processing.Operating System Statistics:The stress on the Oracle server is important, and this section shows the main external resources including I/O, CPU, memory, and network usage. (主要的外部资源的使用(i/o cpu 内存网络)Service Statistics:The service statistics section gives information about how particular services configured in the database are operating.(特殊的服务如何运行)SQL Section: This section displays top SQL, ordered by important SQL execution metrics.SQL Ordered by Elapsed Time: Includes SQL statements that took significant execution time(执行时间长的语句)during processing.SQL Ordered by CPU Time:Includes SQL statements that consumed significant CPU time(花费cpu多的语句)during its processing.SQL Ordered by Gets:These SQLs performed a high number of logical reads while retrieving data.(逻辑读多的语句)SQL Ordered by Reads:These SQLs performed a high number of physical disk reads while retrieving data.(物理读多的语句)SQL Ordered by Parse Calls: These SQLs experienced a high number of reparsing operations.(重新解析多的语句)SQL Ordered by Sharable Memory:Includes SQL statements cursors which consumeda large amount of SGA shared pool memory.SQL Ordered by Version Count: These SQLs have a large number of versions in shared pool for some reason.Instance Activity Stats: This section contains statistical informationdescribing how the database operated during the snapshot period.Instance Activity Stats(Absolute Values): This section contains statistics that have absolute values not derived from end and start snapshots. Instance Activity Stats (Thread Activity): This report section reports a log switch activity statistic.I/O Section: This section shows the all important I/O activity for the instance and shows I/O activity by tablespace, data file, and includes buffer pool statistics.Tablespace IO StatsFile IO StatsBuffer Pool StatisticsAdvisory Section: This section show details of the advisories(指导的细节) for the buffer, shared pool, PGA and Java pool.Buffer Pool AdvisoryPGA Aggr Summary: PGA Aggr Target Stats; PGA Aggr Target Histogram; and PGA Memory Advisory.Shared Pool AdvisoryJava Pool AdvisoryBuffer Wait Statistics: This important section shows buffer cache waits statistics.Enqueue Activity: This important section shows how enqueue operates in the database. Enqueues are special internal structures which provideconcurrent access to various database resources.(控制对数据库资源的并发访问)Undo Segment Summary:This section gives a summary about how undo segments are used by the database.Undo Segment Stats: This section shows detailed history information about undo segment activity.(撤销段活动的历史信息)Latch Activity: This section shows details about latch statistics. Latches are a lightweight serialization mechanism that is used to single-thread access to internal Oracle structures.(轻量型的串行机制,对内部结构的单线程访问)Latch Sleep BreakdownLatch Miss SourcesParent Latch StatisticsChild Latch StatisticsSegment Section: This report section provides details about hot segments using the following criteria:Segments by Logical Reads:Includes top segments which experienced high number of logical reads.Segments by Physical Reads:Includes top segments which experienced high number of disk physical reads.Segments by Buffer Busy Waits:These segments have the largest number of buffer waits caused by their data blocks.Segments by Row Lock Waits: Includes segments that had a large number of row locks on their data.Segments by ITL Waits: Includes segments that had a large contention for Interested Transaction List (ITL). The contention for ITL can be reduced by increasing INITRANS storage parameter of the table.Dictionary Cache Stats: This section exposes details about how the data dictionary cache is operating.Library Cache Activity: Includes library cache statistics describing how shared library objects are managed by Oracle.SGA Memory Summary: This section provides summary information about various SGA regions.init.ora Parameters:This section shows the original init.ora parameters for the instance during the snapshot period.Oracle Database 10g Enhanced wait modelIdle Waits: Whenever an Oracle process has no work to do this is an idle wait. For most processes this is because they are waiting on the user to provide a new SQL statement to execute.Application: These are waits caused by the way the application is designed. These include row lock waits, and table or other locks that are requested by the application either explicitly or implicitly (possibly due to DDL).Configuration: These are waits which occur in a badly configured system and weill be reduced dramatically as a result of proper tuning.Administrative: These are waits imposed by a privileged users by some action.Concurrency: These are waits that can not be tuned and will occur on a system with High Concurrency.Commit: This class only has log file sync. It deserves a special class because it is a necessary event and will be high and is supposed to be high on a system doing queries.Network: All waits due to network messaging delays belong here. They are supposed to point out network congestion or latency. They should not include think or processing time, only the time spent in the networking code and hardware.User I/O Waits: All waits for Disk I/O done by User queries or even SMON, MMONSystem I/O Waits: All waits for Disk I/O done by backgrnd processes like LGWR, DBWR, ARCH, RFS. But not SMON and MMONScheduler: These are waits due to the resource managerCluster: waits which will occur only in RAC mode.Other: All the wait events, which do not fit into one of the above classes clearly, or are not important to classify. By not important I mean those that wait for an insignificant amount of time or really do not fit into any one class.DB问题:1。
如何读懂statspack报告前言:这篇文章是我从网上找到的,但可惜不知道是哪位大侠写(译)的,因此这里无法注明了。
仔细看了看,这篇文章对初学者应该很有帮助,写的比较详细,通俗易懂,因此整理一下,便于阅读;内容略有调整,不单做调整,此记。
产生一个statspack报告是比较简单的,但是如何读懂statspack报告却不是那么容易,需要对Oracle的体系架构、内存结构、等待事件以及应用系统有充分的了解,加上不断的实践,才能基本读懂statspack报告并且从报告中找到调整优化Oracle的途径。
下面接合一个实际的statspack报告,大致分析一下。
1.基本信息分析DB Name DB Id Instance Inst Num Release OPS Host------------ ----------- ------------ -------- ----------- --- --------- ---RES 2749170756 res 1 8.1.7.0.0 NO resSnap Id Snap Time Sessions------- ------------------ --------Begin Snap: 2 26-Jul-03 16:37:08 38End Snap: 3 26-Jul-03 17:03:23 38Elapsed: 26.25 (mins)Statspack报告首先描述了数据库的基本情况,比如数据库名、实例名、实例个数、oracle版本号等等;然后是该报告的开始快照和结束快照的信息,包括snap id , snap time 等等;最后是该报告经过的时间跨度,单位是分钟(mins)。
Cache Sizes (end)~~~~~~~~~~~~~~~~~Buffer Cache: 200M Std Block Size: 8KShared Pool Size: 48M Log Buffer: 512K然后描述了Oracle内存结构中几个重要的参数。
Restock Report库存报告分析通过vlookup可以整理相应ASIN对应的“30天销量”“在途”“可售”,搞到相应的数据便可以分析可售天数、周转率、做库存备货计划、计算库存成本:可售天数=(在途+可售+FC转运)/30天销量*30周转率=30天销量/(在途+可售+FC转运)待发货数量=30天销量/30*计划库存可售天数-在途-可售-FC转运库存成本=(在途+可售+FC转运)*单个产品成本根据自己需求设计Excel模板,设公式即可,以下为两个示例参考示例一:分析周转率及做简易备货计划示例二:分析周转率及库存成本情况ASIN SKU Units Sold Last30Days Inbound Available FC transfer可售天数周转率单个成本FBA+在途库存总成本库存成本/销售占比30天销量在途可售FC转运ASIN1SKU1100008,00010,0001,8005950.5%¥17.00¥170,000.0014.8% ASIN2SKU289007,0005,0001,3004566.9%¥20.00¥178,000.0016.9% ASIN3SKU360007,5005,3004,1008535.5%¥15.00¥90,000.0013.8% ASIN4SKU435003,0001,6008004664.8%¥21.00¥73,500.0021.9% ASIN5SKU525002,6001,0001,6006248.1%¥26.00¥65,000.0018.5% ASIN6SKU622001,2003002,2005059.5%¥20.00¥44,000.0019.5% ASIN7SKU720005004,0006007739.2%¥22.00¥44,000.0019.1% ASIN8SKU819001,7008001,3006050.0%¥20.00¥38,000.0015.6%下载路径:Reports>Fulfillment>Inventory>Restock Inventory,然后点击Request.csv Download 或者Request.txt Download即可生成最新的库存报告附录:常见英文对照表英文中文/解析Country/Region Code国家/站点Product Name产品标题FNSKU FNSKU码/FBA产品编码(条码)Merchant SKU卖家SKU编码(上架SKU编码)ASIN ASIN码Condition产品状况Supplier供应商Supplier part no.供应商产品编码Currency code币种/货币代码Price售价Sales last30days过去30天销售额Units Sold Last30Days过去30天销量(件数)Total Units总产品个数=Inbound+Available+FC transfer Inbound待定入库的数量=Shipped+ReceivingAvailable FBA可售的产品库存数量FC transfer转运中的数量FC Processing调查中的数量Customer Order客户订单保留的库存数量Unfulfillable不可售数量Working处理中的货件中的产品数量Shipped 标记为已发货亚马逊还没开始验收的数量,可片面理解为在途数量,有种情况,亚马逊收到了你的货件,但还没验收,状态还会是Shipped(已发货)Receiving验收中的数量Fulfilled by由谁配送,发FBA的就是亚马逊,自发货的显示的是卖家Total days of supply(including units from open shipments)亚马逊预计你Total Units+Working可售天数,算法不详,仅供参考Days of supply at Amazon fulfillment centers 亚马逊预计你Total Units可售天数,算法不详,仅供参考Alert库存状况警告Recommended replenishment qty建议补货数量Recommended ship date建议补货数量的建议发货日期low_stock低库存/库存不足out_of_stock缺货unassigned未分配。
ORACLEAWR报告生成和分析ORACLEAWR(Automatic Workload Repository)是Oracle数据库中的一个功能,用于收集和存储数据库的性能统计信息。
通过AWR报告,可以分析数据库的性能瓶颈,并提供相关的建议和推荐的解决方案。
下面将对AWR报告的生成和分析进行详细介绍。
AWR报告的生成AWR报告主要由两个组件生成:一是Statspack/SNAP工具(用于收集性能数据),二是AWR报告生成脚本(用于生成AWR报告)。
1. Statspack/SNAP工具Statspack/SNAP工具是Oracle数据库中用于收集数据库性能统计信息的功能。
可以通过以下步骤使用Statspack/SNAP工具收集性能数据:- 创建Statspack/SNAP用户:在数据库中创建一个新用户,用于存储性能统计信息。
- 安装Statspack/SNAP工具:将Statspack/SNAP工具的SQL脚本导入数据库中。
- 创建收集任务:使用Statspack/SNAP工具创建收集任务,指定收集的时间间隔。
- 收集性能数据:定期运行Statspack/SNAP任务,收集数据库的性能统计信息。
2.AWR报告生成脚本AWR报告生成脚本是一个PL/SQL脚本,用于生成AWR报告。
可以通过以下步骤生成AWR报告:-运行AWR报告生成脚本:将AWR报告生成脚本导入数据库中,并运行该脚本。
-指定时间范围:在运行AWR报告生成脚本时,可以指定要分析的时间范围。
- 生成AWR报告:AWR报告生成脚本会从Statspack/SNAP工具导出的数据中提取所需的性能统计信息,并生成AWR报告。
AWR报告的分析生成AWR报告后,可以使用AWR报告进行性能分析。
AWR报告提供了丰富的性能统计信息,可以帮助我们定位和解决数据库性能问题。
1.数据库总览AWR报告的第一部分提供了数据库的总体性能概览,包括数据库版本、实例名称、开始和结束时间等。
详细解读STATSPACK 报告create tablespace perf_tbs datafile '' size 50m ;@/rdbms/admin/executevariable jobno number;(:jobno,';',trunc(sysdate+1/48,'MI'),'trunc(sysdate+1/48,''MI'')');@/rdbms/admin/说在前面,很容易被忽略的几个点:在读报告的时候,我们首先需要看清楚,留意3个内容,这份报告所对应的数据库版本,cluster方式,以及报告的时间段。
尤其需要注意的就是时间段,脱离了时间段的statspck将是毫无意义的,甚至会得出错误的结果。
YAPP方法:传统的优化数据库的指标是各种命中率的统计,并以命中率作为优化的目标。
随着系统和业务模式的发展,这种优化的方法已经过时,YAPP方法由此诞生。
YAPP方法的最终目标就是缩短response time。
Response Time = Service Time + Wait TimeService Time = CPU Parse + CPU Recursive + CPU Other这里的CPU Other可以理解为是SQL语句的执行时间(包括逻辑读等)。
CPU other = CPU used by this session - parse time cpu - recursive cpu usage所以优化的最终目标定位在Service Time 和 Wait Time上:1)当性能问题在Service Time上时,由上面的公式可以看到,解决问题的方向就是SQL语句的优化上面。
2)如果性能问题在Wait Time上,则解决的方向就需要找到具体的等待事件了。
如果等待时间在整个响应时间中占较大的比例,并且主要是块读取相关的等待时,下一步就是找出哪些SQL造成了过多的物理读,可以查看statspack报告中的SQL ordered by Reads部分。
"statspack"的⼀些使⽤技巧: ⼀怎样修改statspack的脚本产⽣⾃定义报表? 通常statspack报表可以满⾜⼤部分的需要,有时我们需要对产⽣报表的脚本进⾏⼀些微⼩的修改,这样产⽣的报表将会更有⽤途。
⽐如说某些SQL很多,但在statspack产⽣的报表中,每个SQL只显⽰5⾏,结果有些⽐较长的SQL就只能看到⼀部分;⼜如在top events部分,标准的报表只显⽰top 5,其实我们可以显⽰更多的events,那如何修改呢?⽤编辑⼯具(在linux下⽤vi)打开($ORACLE_HOME/rdbms/admin/sprepins.sql)define top_n_events = 5; // top 5 eventsdefine top_n_sql = 65; // top sqldefine top_n_segstat = 5; // top 5 segstatdefine num_rows_per_hash=5; // 每个SQL显⽰5⾏ 就看到在该脚本中已经定义了⼀些常数,我们只需要把它改为我们需要的值。
define top_n_events = 10; // top 10 eventsdefine top_n_sql = 65; // top sqldefine top_n_segstat = 10; // top 10 segstatdefine num_rows_per_hash=10; // 每个SQL显⽰10⾏ 修改后,我们就可以看到效果了. ⼆如何⽤statspack的报表确定热表及索引? 如果想⽤statspack表确定热表及索引,必须修改statspack快照的收集级别,8i中statspack共有三种快照级别,默认值是5。
select * from STATS$level_DESCRIPTION;SNAP_LEVEL DESCRIPTION---------- ------------------------- 0 ⼀性性能统计:包含回退段状态、字典缓存、SGA、系统事件、后台事件、会话事件、系统统计、等待统计、锁统计、闩锁统计。
Kappa测试数据分析报告一、引言Kappa 测试是一种用于评估一致性的统计方法,在众多领域都有着广泛的应用。
本次报告旨在对 Kappa 测试数据进行深入分析,以揭示其潜在的规律和趋势,并为相关决策提供有力的支持。
二、数据来源与收集本次分析所使用的数据来源于具体项目名称,通过具体收集方法收集了样本数量个样本。
这些样本涵盖了样本的相关特征和范围,确保了数据的多样性和代表性。
三、Kappa 测试的基本原理Kappa 系数是衡量两个或多个评估者之间一致性的指标,其取值范围在-1 到 1 之间。
当 Kappa 值为 1 时,表示完全一致;当 Kappa 值为0 时,表示一致性与随机猜测相同;当 Kappa 值为负数时,表示一致性比随机猜测还差。
在计算 Kappa 系数时,需要先构建一个列联表,其中行和列分别代表不同评估者的评估结果。
然后,根据列联表中的数据计算预期一致性和实际一致性,最终得出 Kappa 值。
四、数据分析过程1、数据预处理首先,对原始数据进行了清理和筛选,去除了无效和缺失的数据。
同时,对数据进行了编码和标准化处理,以便后续的分析。
2、构建列联表根据预处理后的数据,构建了评估者之间的列联表。
通过列联表,可以直观地看到不同评估者的评估结果分布情况。
3、计算 Kappa 值利用统计软件,计算出了不同评估者之间的 Kappa 值。
结果显示,Kappa 值为具体数值,表明评估者之间的一致性处于具体水平。
4、置信区间估计为了进一步评估 Kappa 值的可靠性,还计算了其置信区间。
通过置信区间,可以了解 Kappa 值的波动范围,以及估计结果的准确性。
五、结果分析与讨论1、一致性水平评估根据计算得到的 Kappa 值,对评估者之间的一致性水平进行了评估。
如果 Kappa 值较高,说明评估者之间的一致性较好;如果 Kappa 值较低,则需要进一步分析原因,可能是评估标准不明确、评估者的经验差异等。
2、影响一致性的因素分析对可能影响一致性的因素进行了分析,如评估者的专业背景、培训程度、评估对象的复杂性等。
Statspack分析之等待事件本文讲述了"等待"在Statspack报告中的意义是什么,以及如何解读它们。
前5个顶级等待事件Statspack报告的第3部分就是TOP 5 WAIT EVENT,例如:Top 5 Timed Events~~~~~~~~~~~~~~~~~~ Event Waits Time (s) % Total Ela Time-------------------------------------------- ------------ ----------- --------db file sequential read 220,409,210 1,086,054 47.33db file scattered read 73,431,629 409,421 17.84CPU time 326,514 14.23 buffer busy waits 36,731,162 136,089 5.93 PX Deq: Execute Reply 4,254,794 118,725 5.17*notes:1)Time的单位为s,cs(1s/100),ms(1s/1000),us(1s/1000000)几种2)如果statitics=true,则按time排序,否则按waits排序,运行statspack时必须设为trueOracle的等待事件是衡量Oracle运行状况的重要依据及指标。
等待事件的概念是在Oracle7.0.1.2中引入的,大致有100个等待事件。
在Oracle 8.0中这个数目增加到了大约150个,在Oracle8i中大约有200个事件,在Oracle9i中大约有360个等待事件。
主要有两种类别的等待事件,即空闲(idle)等待事件和非空闲(non-idle)等待事件。
空闲事件指Oracle正等待某种工作,比如用sqlplus登录之后,但没有进一步发出任何命令,此时该session就处于SQL*Net message from/to client等待事件状态,等待用户发出命令,任何的在诊断和优化数据库的时候,我们不用过多注意这部分事件。
详细解读STATSPACK 报告详细解读 STATSPACK 报告 ...................................1、报表头信息.............................................2、实例负载档信息 ....................... 错误!未指定书签。
3、实例有效性信息 .........................................4、TOP 5及其他等待事件信息................................5、SQL统计信息............................................5.1 SQL统计信息-逻辑读 ......................................................................................................5.2 SQL统计信息-物理读 ......................................................................................................5.3 SQL统计信息-执行次数 ..................................................................................................5.4 SQL统计信息-调用、解析次数 ......................................................................................5.5 SQL统计信息-共享内存占用 ..........................................................................................5.6 SQL统计信息-多版本缓存 ..............................................................................................6、实例的活动信息 .........................................7、I/O统计信息............................................8、Buffer Pool统计信息....................................9、实例的恢复情况统计信息 .................................10、Buffer Pool调整的Advisory ............................11、Buffer Pool等待情况统计...............................12、PGA统计信息...........................................13、PGA调整的Advisory ....................................14、队列的统计信息 ........................................15、回滚段统计信息 ........................................16、闩锁统计信息 ..........................................17、共享池统计信息 ........................................18、SGA内存分配 (34)19、资源限制统计信息 ......................................20、初始化统计信息 ........................................create tablespace perf_tbs datafile '' size 50m ;@?/rdbms/admin/spcreate.sqlexecute statspack.snapvariable jobno number;dbms_job.submit(:jobno,'ststspack.snap;',trunc(sysdate+1/48,'MI'),'trunc(sysdate+1/48,''MI'')');@?/rdbms/admin/spreport.sql说在前面,很容易被忽略的几个点:在读报告的时候,我们首先需要看清楚,留意3个内容,这份报告所对应的数据库版本,cluster方式,以及报告的时间段。
关于Statspack,AWR以及ASH使用Statspack部分Statspack是Oracle 8i以后提供的一个非常好的性能监控与诊断工具。
在数据库管理中,Oracle提供的statspack是一个很强大的工具,通过Statspack,可以收集系统信息,诊断数据库故障,也方便第三方技术支持进行远程阅读和建议。
Oracle Statspack 从Oracle8.1.6开始被引入Oracle,并马上成为DBA和Oracle专家用来诊断数据库性能的强有力的工具。
在oracle10g中被awr取代。
通过Statspack我们可以很容易的确定Oracle数据库的瓶颈所在,记录数据库性能状态。
因此了解和使用Statspack对于DBA来说至关重要。
Statspack的脚本位于$ORACLE_HOME/rdbms/admin目录下。
第一部分statspack安装以及卸载Statspack安装安装statspack至少需要100M表空间,如果需要长期监控,这个表空间应该设置的大一些。
Statspack相关数据不要放到system表空间。
在官方文档中明确指出在system表空间中不支持。
Statspack安装脚本位于:Unix:$ORACLE_HOME/rdbms/admin/spcreate.sqlWindow:%ORACLE_HOME%\rdbms\admin\spcreate.sql下面就以window下安装为例子介绍下statspack的安装过程以及出现问题如何处理:首先执行%ORACLE_HOME\rdbms\admin\spcreate.sql然后会提示你输入perfstat用户密码,指定默认表空间以及temporary表空间:下面白色部分已经明确指出system表空间不支持。
检查当前目录下spcusr.lis,spctab.lis和spcpkg.lis这三个文件,这三个文件记录安装过程所有记录,如果有问题可以使用%ORACLE_HOME\rdbms\admin\spdrop.sql删除后再重新安装1. spcusr -> 建用户和授予权限2. spctab -> 建表同义词索引等记录3. spcpkg -> 建包记录在unix下也可以用batch模式安装:SQL> connect / as sysdbaSQL> define default_tablespace='perfstat'SQL> define temporary_tablespace='temp'SQL> define perfstat_password='perfstat'SQL> @?/rdbms/admin/spcreate.sqlSQL> undefine perfstat_passwordstatspack的卸载Statspack卸载脚本位于:Unix:$ORACLE_HOME/rdbms/admin/spdrop.sqlWindow:%ORACLE_HOME%\rdbms\admin\spdrop.sql下面以window下卸载为例子介绍下statspack的卸载:执行%ORACLE_HOME\rdbms\admin\spcreate.sql执行完毕后,它会提示你去检查当前目录下的spdusr.lis和spdtab.lis文件Statspack数据清理(清理全部数据)当存放statspack的表空间快满的时候需要我们去清理表空间,操作如下:Statspack清理脚本位于:Unix:$ORACLE_HOME/rdbms/admin/sptrunc.sqlWindow:%ORACLE_HOME%\rdbms\admin\ sptrunc.sql下面以window下清理为例子介绍下statspack数据清理:执行%ORACLE_HOME\rdbms\admin\ sptrunc.sqlStatspack数据清理(清理指定数据)当存放statspack的表空间快满的时候需要我们去清理表空间,操作如下:Statspack清理脚本位于:Unix:$ORACLE_HOME/rdbms/admin/sppurge.sqlWindow:%ORACLE_HOME%\rdbms\admin\ sppurge.sql下面以window下清理为例子介绍下statspack数据清理:执行%ORACLE_HOME\rdbms\admin\ sppurge.sql下面会列出能清理的相关时间收集的统计信息:下面提示你输入开始和结束时间点,我们上面的是6,7,8,9,这四个数字代表相应时间,我执行这四次操作是连续做的,时间看起来不明显。
大数据系统应用数据现状分析报告范文模板Data plays an increasingly important role in today's world, and the widespread adoption of big data systems has significantly impacted various industries. In this analysis report, we will explore the current state of data application in big data systems.当前,大数据系统在各行各业中得到了广泛的应用。
然而,虽然人们逐渐认识到数据的重要性,但在实际应用中仍存在一些挑战。
Firstly, we need to acknowledge that the volume of data being generated is growing at an unprecedented rate. This enormous amount of data poses a challenge in terms of storage and processing capabilities. Big data systems must be able to handle petabytes or even exabytes of data efficiently.我们需要意识到正在产生的数据量正在以前所未有的速度增长。
这么庞大的数据量对存储和处理能力提出了挑战。
大数据系统必须能够高效地处理数百甚至数十亿字节级别的数据。
Another challenge lies in ensuring the quality and reliability of the data being ingested into big data systems. The diverse sources and formats of incoming data require robust mechanisms for data cleansing, transformation, and integration. Without proper validation and verification processes, the accuracy and integrity of the final analysis may be compromised.另一个挑战是确保将数据纳入大数据系统时的质量和可靠性。
详细解读 STATSPACK 报告1、报表头信息2、实例负载档信息3、实例有效性信息4、TOP 5及其他等待事件信息5、SQL统计信息5.1 SQL统计信息-逻辑读5.2 SQL统计信息-物理读5.3 SQL统计信息-执行次数5.4 SQL统计信息-调用、解析次数5.5 SQL统计信息-共享内存占用5.6 SQL统计信息-多版本缓存6、实例的活动信息7、I/O统计信息8、Buffer Pool统计信息9、实例的恢复情况统计信息10、Buffer Pool调整的Advisory11、Buffer Pool等待情况统计12、PGA统计信息13、PGA调整的Advisory14、队列的统计信息15、回滚段统计信息16、闩锁统计信息17、共享池统计信息18、SGA内存分配19、资源限制统计信息20、初始化统计信息说在前面,很容易被忽略的几个点:在读报告的时候,我们首先需要看清楚,留意3个内容,这份报告所对应的数据库版本,cluster方式,以及报告的时间段。
尤其需要注意的就是时间段,脱离了时间段的statspck将是毫无意义的,甚至会得出错误的结果。
STATSPACK report for1、报表头信息/* 报表头信息,数据库实例相关信息,包括数据库名称、ID、版本号及主机明等信息。
另外,重点还需要关注一下报告产生的时间跨度(在这里是14分钟),以及并发数(在这里是272)。
DB Name DB Id Instance Inst Num Release Cluster Host------------ ----------- ------------ -------- ----------- ------- ------------ORA92 1924035339 ora92 19.2.0.6.0NO jsdxh_db02Snap Id Snap Time Sessions Curs/Sess Comment--------- ------------------ -------- ----------------------------Begin Snap: 13 14-Jul-07 00:18:52 274 55,345.0End Snap: 14 14-Jul-07 00:32:55 272 55,823.8Elapsed: 14.05 (mins)Cache Sizes (end)~~~~~~~~~~~~~~~~~Buffer Cache: 5,120M Std BlockSize: 8KShared Pool Size: 400M LogBuffer: 2,048K2、实例负载档信息Load Profile~~~~~~~~~~~~ Per Second Per Transaction--------------- ---------------Redosize: 422,086.46 4,706.23Logicalreads: 23,200.54 258.68Blockchanges: 3,080.59 34.35Physicalreads: 31.46 0.35Physicalwrites: 104.38 1.16Usercalls: 409.32 4.56Parses: 227.20 2 .53Hardparses: 7.22 0.08Sorts: 213.87 2 .38Logons: 0.85 0 .01Executes: 1,191.32 13 .28Transactions: 89.69/* 下面详细说明Load Profile各项含义Redo size:每秒产生的日志大小(单位字节),可标志数据变更频率, 数据库任务的繁重与否。
Logical reads:平决每秒产生的逻辑读的block数。
Logical Reads= Consistent Gets + DB Block Gets Block changes:每秒block变化数量,数据库事物带来改变的块数量。
Physical reads:平均每秒数据库从磁盘读取的block数。
Physical writes:平均每秒数据库写磁盘的block数。
User calls:每秒用户调用次数。
Parses:每秒解析次数,包括fast parse,soft parse和hard parse三种数量的综合。
软解析每秒超过300次意味着你的"应用程序"效率不高,调整session_cursor_cache。
在这里,fast parse指的是直接在PGA中命中的情况(设置了session_cached_cursors=n);soft parse是指在shared pool中命中的情形;hard parse则是指都不命中的情况。
Hard parses:每秒产生的硬解析次数, 每秒超过100次,就可能说明你绑定使用的不好,也可能是共享池设置不合理。
这时候可以启用参数cursor_sharing=similar|force,该参数默认值为exact。
但该参数设置为similar时,存在bug,可能导致执行计划的不优。
Sorts:每秒产生的排序次数。
Logons:每秒登陆的次数。
Executes:每秒执行次数。
Transactions:每秒产生的事务数,反映数据库任务繁重与否。
% Blocks changed per Read: 13.28 Recursive Call %: 80.21 Rollback per transaction %: 0.03 Rows per Sort: 2.84/* Load Profile 续1) % Blocks changed per Read:在每一次逻辑读中更改的块的百分比。
2) Rollback per transaction %:看回滚率是不是很高,因为回滚很耗资源 ,如果回滚率过高,可能说明你的数据库经历了太多的无效操作 ,过多的回滚可能还会带来Undo Block的竞争该参数计算公式如下: Round(User rollbacks / (user commits + user rollbacks) ,4)* 100% 。
3) Recursive Call %:递归调用的百分比,如果有很多PL/SQL,那么这个值就会比较高。
4) Rows per Sort:平均每次排序操作的行数。
3、实例有效性信息Instance Efficiency Percentages (Target 100%)~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~Buffer Nowait %: 99.98 Redo NoWait %: 100.00 Buffer Hit %: 99.87 In-memory Sort %: 100.00 Library Hit %: 99.67 Soft Parse %: 96.82Execute to Parse %: 80.93 Latch Hit %: 96.10 Parse CPU to Parse Elapsd %: 6.93 % Non-Parse CPU: 99.88/* 实例的有效性,这部分值越接近100越好,分项内容详细说明如下:1) Buffer Nowait %:在缓冲区中获取Buffer的未等待比率。
Buffer Nowait的这个值一般需要大于99%。
否则可能存在争用,可以在后面的等待事件中进一步确认。
2) Redo NoWait %:在Redo缓冲区获取Buffer空间的未等待比率。
当redo buffer达到1M时,就需要写到redo log文件,所以一般当redo buffer设置超过1M,不太可能存在等待buffer空间分配的情况。
当前,一般设置为2M的redo buffer,对于内存总量来说,应该不是一个太大的值。
3) Buffer Hit %:数据块在数据缓冲区中的命中率,通常应在95%以上。
否则,小于95%,需要调整重要的参数,小于90%可能是要加db_cache_size。
一个高的命中率,不一定代表这个系统的性能是最优的,比如大量的非选择性的索引被频繁访问,就会造成命中率很高的假相(大量的db file sequential read),但是一个比较低的命中率,一般就会对这个系统的性能产生影响,需要调整。
命中率的突变,往往是一个不好的信息。
如果命中率突然增大,可以检查top buffer get SQL,查看导致大量逻辑读的语句和索引,如果命中率突然减小,可以检查top physical reads SQL,检查产生大量物理读的语句,主要是那些没有使用索引或者索引被删除的。
4) In-memory Sort %:在内存中的排序率。
如果低于95%,可以通过适当调大初始化参数PGA_AGGREGATE_TARGET或者SORT_AREA_SIZE来解决,注意这两个参数设置作用的范围时不同的,SORT_AREA_SIZE是针对每个session设置的,PGA_AGGREGATE_TARGET则时针对所有的sesion的。
5) Library Hit %:STATEMENT在共享区的命中率,通常应该保持在95%以上,否则需要要考虑:加大共享池;使用绑定变量;修改cursor_sharing等参数。
6) Soft Parse %:sql在共享区的命中率,小于<95%,需要考虑绑定,如果低于80%,那么就可以认为sql基本没有被重用。
7) Execute to Parse %:一个语句执行和分析了多少次的度量。
计算公式为:Execute to Parse =100* (1 - Parses/Executions)。
本例中,差不多每execution 5次需要一次parse。
所以如果系统Parses > Executions,就可能出现该比率小于0的情况。
该值<0通常说明shared pool设置或者语句效率存在问题,造成反复解析,reparse可能较严重,或者是可能同snapshot有关,通常说明数据库性能存在问题。
8) Latch Hit %:要确保>99%,否则存在严重的性能问题。
当该值出现问题的时候,我们可以借助后面的等待时间和latch分析来查找解决问题。
9) Parse CPU to Parse Elapsd %:计算公式为:Parse CPU to Parse Elapsd %= 100*(parse timecpu / parse time elapsed)。
即:解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。