详细解读 STATSPACK 报告
详细解读 STATSPACK 报告 (1)
1、报表头信息 (2)
2、实例负载档信息 (2)
3、实例有效性信息 (3)
4、TOP 5及其他等待事件信息 (5)
5、SQL统计信息 (10)
5.1 SQL统计信息－逻辑读 (11)
5.2 SQL统计信息－物理读 (11)
5.3 SQL统计信息－执行次数 (12)
5.4 SQL统计信息－调用、解析次数 (12)
5.5 SQL统计信息－共享内存占用 (13)
5.6 SQL统计信息－多版本缓存 (13)
6、实例的活动信息 (14)
7、I/O统计信息 (18)
8、Buffer Pool统计信息 (20)
9、实例的恢复情况统计信息 (21)
10、Buffer Pool调整的Advisory (21)
11、Buffer Pool等待情况统计 (22)
12、PGA统计信息 (22)
13、PGA调整的Advisory (23)
14、队列的统计信息 (24)
15、回滚段统计信息 (24)
16、闩锁统计信息 (26)
17、共享池统计信息 (31)
18、SGA内存分配 (32)
19、资源限制统计信息 (33)
20、初始化统计信息 (34)
说在前面，很容易被忽略的几个点：在读报告的时候，我们首先需要看清楚，留意3个内容，这份报告所对应的数据库版本，cluster方式，以及报告的时间段。尤其需要注意的就是时间段，脱离了时间段的statspck将是毫无意义的，甚至会得出错误的结果。
STATSPACK report for
1、报表头信息
/* 报表头信息，数据库实例相关信息，包括数据库名称、ID、版本号及主机明等信息。
另外，重点还需要关注一下报告产生的时间跨度（在这里是14分钟），以及并发数（在这里是272）。 DB Name DB Id Instance Inst Num Release Cluster Host
------------ ----------- ------------ -------- ----------- ------- ------------ ORA92 1924035339 ora92 1 9.2.0.6.0NO jsdxh_db02
Snap Id Snap Time Sessions Curs/Sess Comment
--------- ------------------ -------- --------- ------------------- Begin Snap: 13 14-Jul-07 00:18:52 274 55,345.0
End Snap: 14 14-Jul-07 00:32:55 272 55,823.8
Elapsed: 14.05 (mins)
Cache Sizes (end)
~~~~~~~~~~~~~~~~~
Buffer Cache: 5,120M Std Block Size: 8K
Shared Pool Size: 400M Log Buffer: 2,048K 2、实例负载档信息
Load Profile
~~~~~~~~~~~~ Per Second Per Transaction
--------------- ---------------
Redo size: 422,086.46 4,706.23
Logical reads: 23,200.54 258.68
Block changes: 3,080.59 34.35
Physical reads: 31.46 0.35
Physical writes: 104.38 1.16
User calls: 409.32 4.56
Parses: 227.20 2.53
Hard parses: 7.22 0.08
Sorts: 213.87 2.38
Logons: 0.85 0.01
Executes: 1,191.32 13.28
Transactions: 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.82
Execute 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 time cpu
/ parse time elapsed)。即：解析实际运行时间/(解析实际运行时间+解析中等待资源时间)。如果该比率为100%，意味着CPU等待时间为0，没有任何等待。
10)% Non-Parse CPU：计算公式为：% Non-Parse CPU =round(100*1-PARSE_CPU/TOT_CPU),2)。如果这
个值比较小，表示解析消耗的CPU时间过多。与PARSE_CPU相比，如果TOT_CPU很高，这个比值将接近100%，这是很好的，说明计算机执行的大部分工作是执行查询的工作，而不是分析查询的工作。
Shared Pool Statistics Begin End
------ ------
Memory Usage %: 32.87 33.12
% SQL with executions>1: 80.00 82.69
% Memory for SQL w/exec>1: 77.62 80.70
1)Memory Usage %：正在使用的共享池的百分率。这个数字应该长时间稳定在75%～90%。如果这个百分
比太低，表明共享池设置过大，带来额外的管理上的负担，从而在某些条件下会导致性能的下降。如果这个百分率太高，会使共享池外部的组件老化，如果SQL语句被再次执行，这将使得SQL语句被硬解析。在一个大小合适的系统中，共享池的使用率将处于75%到略低于90%的范围内。
2)% SQL with executions>1：这是在共享池中有多少个执行次数大于一次的SQL语句的度量。在一个
趋向于循环运行的系统中，必须认真考虑这个数字。在这个循环系统中，在一天中相对于另一部分时间的部分时间里执行了一组不同的SQL语句。在共享池中，在观察期间将有一组未被执行过的SQL语句，这仅仅是因为要执行它们的语句在观察期间没有运行。只有系统连续运行相同的SQL语句组，这个数字才会接近100%。这里显示，在这个共享池中几乎有80%的SQL语句在14分钟的观察窗口中运行次数多于一次。剩下的20%的语句可能已经在那里了--系统只是没有去执行。
3)% Memory for SQL w/exec>1：这是与不频繁使用的SQL语句相比，频繁使用的SQL语句消耗内存多
少的一个度量。这个数字将在总体上与% SQL with executions>1非常接近，除非有某些查询任务消耗的内存没有规律。在稳定状态下，总体上会看见随着时间的推移大约有75%～85%的共享池被使用。
如果Statspack报表的时间窗口足够大到覆盖所有的周期，执行次数大于一次的SQL语句的百分率应该接近于100%。这是一个受观察之间持续时间影响的统计数字。可以期望它随观察之间的时间长度增大而增大。
小结：通过ORACLE的实例有效性统计数据，我们可以获得大概的一个整体印象，然而我们并不能由此来确定数据运行的性能。当前性能问题的确定，我们主要还是依靠下面的等待事件来确认。我们可以这样理解两部分的内容，hit统计帮助我们发现和预测一些系统将要产生的性能问题，由此我们可以做到未雨绸缪。而wait事件，就是表明当前数据库已经出现了性能问题需要解决，所以是亡羊补牢的性质。
接下来，开始查看wait事件。
4、TOP 5及其他等待事件信息
/* oracle等待事件是衡量oracle运行状况的重要依据及指示，等待事件分为两类：空闲等待事件和非空闲等待事件, TIMED_STATISTICS = TRUE 那么等待事件按等待的时间排序，= FALSE那么事件按等待的数量排序。运行statspack期间必须session上设置TIMED_STATISTICS = TRUE，否则统计的数据将失真。空闲等待事件是oracle正等待某种工作，在诊断和优化数据库时候，不用过多注意这部分事件，非空闲等待事件专门针对oracle的活动，指数据库任务或应用程序运行过程中发生的等待，这些等待事件是我们在调整数据库应该关注的。
对于常见的等待事件，说明如下：
1)db file scattered read
该事件通常与全表扫描或者fast full index scan有关。因为全表扫描是被放入内存中进行的进行的，通常情况下基于性能的考虑，有时候也可能是分配不到足够长的连续内存空间，所以会将数据块分散(scattered)读入Buffer Cache中。该等待过大可能是缺少索引或者没有合适的索引(可以调整optimizer_index_cost_adj) 。这种情况也可能是正常的，因为执行全表扫描可能比索引扫描效率更高。当系统存在这些等待时，需要通过检查来确定全表扫描是否必需的来调整。因为全表扫描被置于LRU(Least Recently Used，最近最少适用)列表的冷端(cold end)，对于频繁访问的较小的数据表，可以选择把他们Cache 到内存中，以避免反复读取。当这个等待事件比较显著时，可以结合v$session_longops 动态性能视图来进行诊断，该视图中记录了长时间(运行时间超过6 秒的)运行的事物，可能很多是全表扫描操作(不管怎样，这部分信息都是值得我们注意的)。
关于参数OPTIMIZER_INDEX_COST_ADJ＝n：该参数是一个百分比值，缺省值为100，可以理解为FULL SCAN COST/INDEX SCAN COST。当n%* INDEX SCAN COST 在具体设置的时候，我们可以根据具体的语句来调整该值。如果我们希望某个statement使用索引，而实际它确走全表扫描，可以对比这两种情况的执行计划不同的COST，从而设置一个更合适的值。 2)db file sequential read：该事件说明在单个数据块上大量等待，该值过高通常是由于表间连接顺 序很糟糕（没有正确选择驱动行源），或者使用了非选择性索引。通过将这种等待与statspack报表中已知其它问题联系起来(如效率不高的sql),通过检查确保索引扫描是必须的，并确保多表连接的连接顺序来调整。 3)buffer busy wait：当缓冲区以一种非共享方式或者如正在被读入到缓冲时,就会出现该等待。该值 不应该大于1%。当出现等待问题时，可以检查缓冲等待统计部分(或V$WAITSTAT)，确定该等待发生在什么位置： a)如果等待是否位于段头(Segment Header)。这种情况表明段中的空闲列表（freelist）的块比 较少。可以考虑增加空闲列表(freelist，对于Oracle8i DMT)或者增加freelist groups(在很 多时候这个调整是立竿见影的(alter table tablename strorage(freelists 2))，在8.1.6之 前，这个freelists参数不能动态修改;在8.1.6及以后版本，动态修改feelists需要设置 COMPATIBLE至少为8.1.6)。也可以增加PCTUSED与PCTFREE之间距离（PCTUSED-to-pctfree gap），其实就是说降低PCTUSED的值，尽快使块返回freelist列表被重用。如果支持自动段 空间管理（ASSM），也可以使用ASSM模式，这是在ORALCE 920以后的版本中新增的特性。 b)如果这一等待位于undo header，可以通过增加回滚段(rollback segment)来解决缓冲区的问题。 c)如果等待位于undo block上，我们需要增加提交的频率，使block可以尽快被重用；使用更大 的回滚段；降低一致读所选择的表中数据的密度；增大DB_CACHE_SIZE。 d)如果等待处于data block，表明出现了hot block，可以考虑如下方法解决： ①将频繁并发访 问的表或数据移到另一数据块或者进行更大范围的分布(可以增大pctfree值 ，扩大数据分布， 减少竞争)，以避开这个"热点"数据块。②也可以减小数据块的大小，从而减少一个数据块中的 数据行数，降低数据块的热度，减小竞争；③检查对这些热块操作的SQL语句，优化语句。④ 增加hot block上的initrans值。但注意不要把initrans值设置的过于高了，通常设置为5 就足够了。因为增加事务意味着要增加ITL事务槽，而每个ITL事务槽将占用数据块中24个字 节长度。默认情况下，每个数据块或者索引块中是ITL槽是2个，在增加initrans的时候，可 以考虑增大数据块所在的表的PCTFREE值，这样Oracle会利用PCTFREE部分的空间增加ITL slot 数量，最大达到maxtrans指定。 e)如果等待处于index block，应该考虑重建索引、分割索引或使用反向键索引。为了防止与数据 块相关的缓冲忙等待，也可以使用较小的块，在这种情况下，单个块中的记录就较少，所以这 个块就不是那么"繁忙"。或者可以设置更大的PCTFREE,使数据扩大物理分布，减少记录间的热 点竞争。在执行DML (insert/update/ delete)时，Oracle向数据块中写入信息，对于多事务 并发访问的数据表，关于ITL的竞争和等待可能出现，为了减少这个等待，可以增加initrans， 使用多个ITL槽。在Oracle9i 中，可以使用ASSM这个新特性Oracle 使用位图来管理空间使 用，减小争用。 4)latch free：当闩锁丢失率高于0.5%时，需要调整这个问题。详细的我们在后面的Latch Activity for DB部分说明。 5)Enqueue 队列是一种锁，保护一些共享资源，防止并发的DML操作。队列采用FIFO策略，注意latch 并不是采用的FIFO机制。比较常见的有3种类型的队列：ST队列，HW队列，TX4队列。 ST Enqueue的等待主要是在字典管理的表空间中进行空间管理和分配时产生的。解决方法：1）将字典管理的表空间改为本地管理模式 2）预先分配分区或者将有问题的字典管理的表空间的next extent设置大一些。 HW Enqueue是用于segment的HWM的。当出现这种等待的时候，可以通过手工分配etents来解决。 TX4 Enqueue等待是最常见的等待情况。通常有3种情况会造成这种类型的等待：1）唯一索引中的重复索引。解决方法：commit或者rollback以释放队列。 2）对同一个位图索引段（bitmap index fragment）有多个update，因为一个bitmap index fragment可能包含了多个rowid，所以当多个用户更新时，可能一个用户会锁定该段，从而造成等待。解决方法同上。3）有多个用户同时对一个数 据块作update，当然这些DML操作可能是针对这个数据块的不同的行，如果此时没有空闲的ITL槽，就会产生一个block-level锁。解决方法：增大表的initrans值使创建更多的ITL槽；或者增大表的pctfree值，这样oracle可以根据需要在pctfree的空间创建更多的ITL槽；使用smaller block size，这样每个块中包含行就比较少，可以减小冲突发生的机会。 6)Free Buffer：这个等待事件表明系统正在等待内存中的可用空间，这说明当前Buffer 中已经没有 Free 的内存空间。如果应用设计良好，SQL 书写规范，充分绑定变量，那这种等待可能说明Buffer Cache 设置的偏小，你可能需要增大DB_CACHE_SIZE。该等待也可能说明DBWR 的写出速度不够，或者磁盘存在严重的竞争，可以需要考虑增加检查点、使用更多的DBWR 进程，或者增加物理磁盘的数量,分散负载，平衡IO。 7)Log file single write：该事件仅与写日志文件头块相关，通常发生在增加新的组成员和增进序列 号时。头块写单个进行，因为头块的部分信息是文件号，每个文件不同。更新日志文件头这个操作在后台完成，一般很少出现等待，无需太多关注。 8)log file parallel write：从log buffer 写redo 记录到redo log 文件，主要指常规写操作(相对 于log file sync)。如果你的Log group 存在多个组成员，当flush log buffer 时，写操作是并行的，这时候此等待事件可能出现。尽管这个写操作并行处理，直到所有I/O 操作完成该写操作才会完成(如果你的磁盘支持异步IO或者使用IO SLAVE，那么即使只有一个redo log file member,也有可能出现此等待)。这个参数和log file sync 时间相比较可以用来衡量log file 的写入成本。通常称为同步成本率。改善这个等待的方法是将redo logs放到I/O快的盘中，尽量不使用raid5，确保表空间不是处在热备模式下，确保redo log和data的数据文件位于不同的磁盘中。 9)log file sync：当一个用户提交或回滚数据时，LGWR将会话的redo记录从日志缓冲区填充到日志文 件中，用户的进程必须等待这个填充工作完成。在每次提交时都出现，如果这个等待事件影响到数据库性能，那么就需要修改应用程序的提交频率, 为减少这个等待事件，须一次提交更多记录，或者将重做日志REDO LOG 文件访在不同的物理磁盘上，提高I/O的性能。 10)log buffer space：日志缓冲区写的速度快于LGWR写REDOFILE的速度,可以增大日志文件大小，增 加日志缓冲区的大小，或者使用更快的磁盘来写数据。 11)logfile switch：通常是因为归档速度不够快。表示所有的提交(commit)的请求都需要等待"日志文 件切换"的完成。Log file Switch 主要包含两个子事件: log file switch (archiving needed) 这个等待事件出现时通常是因为日志组循环写满以后，第一个日志归档尚未完成，出现该等待。出现该等待，可能表示io 存在问题。解决办法:①可以考虑增大日志文件和增加日志组；②移动归档文件到快速磁盘；③调整log_archive_max_processes。 log file switch (checkpoint incomplete) 当日志组都写完以后，LGWR 试图写第一个log file，如果这时数据库没有完成写出记录在第一个log file 中的dirty 块时(例如第一个检查点未完成)，该等待事件出现。该等待事件通常表示你的DBWR 写出速度太慢或者IO 存在问题。为解决该问题，你可能需要考虑增加额外的DBWR 或者增加你的日志组或日志文件大小，或者也可以考虑增加checkpoint的频率。 12)DB File Parallel Write：文件被DBWR并行写时发生。解决办法：改善IO性能。 13)DB File Single Write：当文件头或别的单独块被写入时发生，这一等待直到所有的I/O调用完成。 解决办法：改善IO性能。 14)DB FILE Scattered Read：当扫描整个段来根据初始化参数db_file_multiblock_read_count读取多 个块时发生，因为数据可能分散在不同的部分，这与分条或分段）相关，因此通常需要多个分散的读来读取所有的数据。等待时间是完成所有I/O调用的时间。解决办法：改善IO性能。 15)DB FILE Sequential Read：当前台进程对数据文件进行常规读时发生，包括索引查找和别的非整段 扫描以及数据文件块丢弃等待。等待时间是完成所有I/O调用的时间。解决办法：改善IO性能。 16)Direct Path Read：一般直接路径读取是指将数据块直接读入PGA中。一般用于排序、并行查询和read ahead操作。这个等待可能是由于I/O造成的。使用异步I/O模式或者限制排序在磁盘上，可能会降低这里的等待时间。 17)direct path write：直接路径写该等待发生在，系统等待确认所有未完成的异步I/O 都已写入磁盘。 对于这一写入等待，我们应该找到I/O 操作最为频繁的数据文件(如果有过多的排序操作，很有可能就是临时文件)，分散负载，加快其写入操作。如果系统存在过多的磁盘排序，会导致临时表空间操作频繁，对于这种情况，可以考虑使用Local管理表空间，分成多个小文件，写入不同磁盘或者裸设备。 18)control file parallel write：当server 进程更新所有控制文件时，这个事件可能出现。如果等待 很短，可以不用考虑。如果等待时间较长，检查存放控制文件的物理磁盘I/O 是否存在瓶颈。 多个控制文件是完全相同的拷贝，用于镜像以提高安全性。对于业务系统，多个控制文件应该存放在不同的磁盘上，一般来说三个是足够的，如果只有两个物理硬盘，那么两个控制文件也是可以接受的。 在同一个磁盘上保存多个控制文件是不具备实际意义的。减少这个等待，可以考虑如下方法:①减少控制文件的个数(在确保安全的前提下)。②如果系统支持，使用异步IO。③转移控制文件到IO 负担轻的物理磁盘。 19)control file sequential read control file single write ：控制文件连续读/控制文件单个写对单个控制文件I/O 存在问题时，这两个事件会出现。如果等待比较明显，检查单个控制文件，看存放位置是否存在I/O 瓶颈。 对于常见的一些IDLE wait事件举例： dispatcher timer lock element cleanup Null event parallel query dequeue wait parallel query idle wait - Slaves pipe get PL/SQL lock timer pmon timer- pmon rdbms ipc message slave wait smon timer SQL*Net break/reset to client SQL*Net message from client SQL*Net message to client SQL*Net more data to client virtual circuit status client message SQL*Net message from client 下面是关于这里的常见的等待事件和解决方法的一个快速预览 等待事件 一般解决方法 Sequential Read 调整相关的索引和选择合适的驱动行源 Scattered Read 表明出现很多全表扫描。优化code，cache小表到内存中。 Free Buffer 增大DB_CACHE_SIZE，增大checkpoint的频率，优化代码 Buffer Busy Segment header 增加freelist或者freelistgroups Buffer Busy Data block 隔离热块；使用反转索引；使用更小的块；增大表的initrans Buffer Busy Undo header 增加回滚段的数量或者大小 Buffer Busy Undo block Commit more；增加回滚段的数量或者大小 Latch Free 检查具体的等待latch类型，解决方法参考后面介绍 Enqueue–ST 使用本地管理的表空间或者增加预分配的盘区大小 Enqueue–HW 在HWM之上预先分配盘区 Enqueue–TX4 在表或者索引上增大initrans的值或者使用更小的块 Log Buffer Space 增大LOG_BUFFER，改善I/O Log File Switch 增加或者增大日志文件 Log file sync 减小提交的频率；使用更快的I/O；或者使用裸设备 Write complete waits 增加DBWR；提高CKPT的频率； Top 5 Timed Events ~~~~~~~~~~~~~~~~~~ % Total Event Waits Time (s) Ela Time -------------------------------------------- ------------ ----------- -------- CPU time 361 54.14 log file sync 74,324 101 15.22 enqueue 729 88 13.28 db file sequential read 7,303 65 9.76 SQL*Net message from dblink 482 20 3.05 Wait Events for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> s - second -> cs - centisecond - 100th of a second -> ms - millisecond - 1000th of a second -> us - microsecond - 1000000th of a second -> ordered by wait time desc, waits desc (idle events last) Avg Total Wait wait Waits Event Waits Timeouts Time (s) (ms) /txn ---------------------------- ------------ ---------- ---------- ------ -------- log file sync 74,324 0 101 1 1.0 enqueue 729 0 88 121 0.0 db file sequential read 7,303 0 65 9 0.1 SQL*Net message from dblink 482 0 20 42 0.0 db file parallel write 725 0 14 19 0.0 db file scattered read 2,415 0 6 3 0.0 process startup 8 0 4 440 0.0 latch free 1,307 1,300 2 1 0.0 log file parallel write 67,042 0 2 0 0.9 control file sequential read 269 0 1 3 0.0 single-task message 24 0 1 33 0.0 control file parallel write 325 0 1 2 0.0 buffer busy waits 3,368 0 1 0 0.0 log file switch completion 19 0 0 20 0.0 direct path read 288 0 0 0 0.0 LGWR wait for redo copy 1,032 0 0 0 0.0 SQL*Net more data to client 1,390 0 0 0 0.0 kksfbc child completion 1 1 0 10 0.0 log file sequential read 2 0 0 5 0.0 direct path write 128 0 0 0 0.0 library cache pin 14 0 0 0 0.0 SQL*Net more data from dblin 4 0 0 0 0.0 log file single write 2 0 0 1 0.0 SQL*Net message to dblink 482 0 0 0 0.0 buffer deadlock 30 30 0 0 0.0 SQL*Net message from client 436,773 0 143,221 328 5.8 jobq slave wait 2,688 1,664 6,688 2488 0.0 wakeup time manager 27 27 791 29297 0.0 SQL*Net message to client 436,772 0 0 0 5.8 Background Wait Events for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> ordered by wait time desc, waits desc (idle events last) Avg Total Wait wait Waits Event Waits Timeouts Time (s) (ms) /txn ---------------------------- ------------ ---------- ---------- ------ -------- db file parallel write 725 0 14 19 0.0 log file parallel write 67,044 0 2 0 0.9 control file sequential read 186 0 1 4 0.0 control file parallel write 325 0 1 2 0.0 db file scattered read 38 0 0 7 0.0 direct path read 288 0 0 0 0.0 LGWR wait for redo copy 1,032 0 0 0 0.0 db file sequential read 3 0 0 6 0.0 log file sequential read 2 0 0 5 0.0 direct path write 128 0 0 0 0.0 log file single write 2 0 0 1 0.0 rdbms ipc message 63,167 1,061 4,970 79 0.8 smon timer 3 3 879 ###### 0.0 pmon timer 292 292 823 2819 0.0 5、SQL统计信息 接下来的部分，是关于SQL的统计信息，分为6块来统计排序： ordered by buffer gets ordered by Physical reads ordered by Executions ordered by Parse Calls ordered by Sharable Memory ordered by Version Count 5.1 SQL统计信息－逻辑读 这一部分，通过Buffer Gets对SQL语句进行排序，即通过它执行了多少个逻辑I/O来排序。顶端的注释表明一个PL/SQL单元的缓存获得(Buffer Gets)包括被这个代码块执行的所有SQL语句的Buffer Gets。因此将经常在这个列表的顶端看到PL/SQL过程，因为存储过程执行的单独的语句的数目被总计出来。 在这里的Buffer Gets是一个累积值，所以这个值大并不一定意味着这条语句的性能存在问题。通常我们可以通过对比该条语句的Buffer Gets和physical reads值，如果这两个比较接近，肯定这条语句是存在问题的，我们可以通过执行计划来分析，为什么physical reads的值如此之高。另外，我们在这里也可以关注gets per exec的值，这个值如果太大，表明这条语句可能使用了一个比较差的索引或者使用了不当的表连接。 另外说明一点：大量的逻辑读往往伴随着较高的CPU消耗。所以很多时候我们看到的系统CPU将近100％的时候，很多时候就是SQL语句造成的，这时候我们可以分析一下这里逻辑读大的SQL。 SQL ordered by Gets for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> End Buffer Gets Threshold: 10000 -> Note that resources reported for PL/SQL includes the resources used by all SQL statements called within the PL/SQL code. As individual SQL statements are also reported, it is possible and valid for the summed total % to exceed 100 CPU Elapsd Buffer Gets Executions Gets per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- ---------- 13,367,435 171 78,172.1 68.3 259.36 353.19 3790040751 DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate; broken BOOLEAN := FALSE; BEGIN P_DXH_DEALOVERTIMEDXHREC; :mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END IF; END …… 5.2 SQL统计信息－物理读 这部分通过物理读对SQL语句进行排序。这显示引起大部分对这个系统进行读取活动的SQL，即物理I/O。当我们的系统如果存在I/O瓶颈时，需要关注这里I/O操作比较多的语句。 SQL ordered by Reads for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> End Disk Reads Threshold: 1000 CPU Elapsd Physical Reads Executions Reads per Exec %Total Time (s) Time (s) Hash Value --------------- ------------ -------------- ------ -------- --------- ---------- 4,187 24 174.5 15.8 0.79 52.99 1895519470 DECLARE job BINARY_INTEGER := :job; next_date DATE := :mydate; broken BOOLEAN := FALSE; BEGIN p_dxh_tmp_importUserInfo2(500); : mydate := next_date; IF broken THEN :b := 1; ELSE :b := 0; END I F; END; 538 21,504 0.0 2.0 5.92 241.61 1725988165 Module: Das.exe begin P_DXH_AddSms(I_CALLERNO=>:V001,I_CALLEENO=>:V002,I_CALLTY PE=>:V003,I_DXHHFLAG=>:V004,O_RET=>:V005);end; …… 5.3 SQL统计信息－执行次数 这部分告诉我们在这段时间中执行次数最多的SQL语句。为了隔离某些频繁执行的查询，以观察是否有某些更改逻辑的方法以避免必须如此频繁的执行这些查询，这可能是很有用的。或许一个查询正在一个循环的内部执行，而且它可能在循环的外部执行一次，可以设计简单的算法更改以减少必须执行这个查询的次数。即使它运行的飞快，任何被执行几百万次的操作都将开始耗尽大量的时间。 SQL ordered by Executions for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> End Executions Threshold: 100 CPU per Elap per Executions Rows Processed Rows per Exec Exec (s) Exec (s) Hash Value ------------ --------------- ---------------- ----------- ---------- ---------- 102,491 0 0.0 0.00 0.00 1053795750 Module: Das.exe COMMIT 48,861 38,275 0.8 0.00 0.00 947217968 Module: Das.exe SELECT T.AREAID FROM T_DXH_MOBILE S, T_DXH_AREA T WHERE S.MOBILE SEGMENT = SUBSTR(:B1 ,1,7) AND T.AREACODE = S.AREACODE AND ROWNU M = 1 5.4 SQL统计信息－调用、解析次数 在这一部分，主要显示PARSE与EXECUTIONS的对比情况。如果PARSE/EXECUTIONS>1，往往说明这个语句可能存在问题：没有使用绑定变量，共享池设置太小，cursor_sharing被设置为exact，没有设置session_cached_cursors等等问题。 SQL ordered by Parse Calls for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> End Parse Calls Threshold: 1000 % Total Parse Calls Executions Parses Hash Value ------------ ------------ -------- ---------- 61,404 30,650 32.06 3303409220 Module: SvcProcessor.exe begin P_DXH_UPDATESUBMITSTATUS(:V00001,:V00002,:V00003,:V00004); end; 1,661 1,661 0.87 140223014 Module: SvcProcessor.exe SELECT SERIALNO, PID, SERVICEID, SMSCONTENT, REPORTFLAG, ORGADDR , DESTADDR, FEEADDR, FEETYPE, FEEUSERTYPE, FEECODE, SPID FROM T_ DXH_OPENDETECT WHERE LOCKFLAG = :B1 5.5 SQL统计信息－共享内存占用 在这一部分，主要是针对shared memory占用的情况进行排序。 SQL ordered by Sharable Memory for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> End Sharable Memory Threshold: 1048576 Sharable Mem (b) Executions % Total Hash Value ---------------- ------------ ------- ------------ 1,115,384 15,112 0.2 3531895589 Module: Das.exe INSERT INTO T_DXH_DXHRECLOG (CALLERNO, CALLEENO, NOTIFYFLAG, SMS TYPE, AREAID, LOGDATE) VALUES (:B4 , :B3 , 1, :B2 , :B1 , TO_CHA R(SYSDATE, 'MMDD')) 5.6 SQL统计信息－多版本缓存 在这一部分，主要是针对SQL语句的多版本进行排序。相同的SQL文本，但是不同属性，比如对象owner 不同，会话优化模式不同、类型不同、长度不同和绑定变量不同等等的语句，他们是不能共享的，所以再缓存中会存在多个不同的版本。这当然就造成了资源上的更多的消耗。 SQL ordered by Version Count for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> End Version Count Threshold: 20 Version Count Executions Hash Value -------- ------------ ------------ 30 15,112 3531895589 Module: Das.exe INSERT INTO T_DXH_DXHRECLOG (CALLERNO, CALLEENO, NOTIFYFLAG, SMS TYPE, AREAID, LOGDATE) VALUES (:B4 , :B3 , 1, :B2 , :B1 , TO_CHA R(SYSDATE, 'MMDD')) 小结： 对于出现在上面的可疑的sql语句，我们可以查看语句相关的执行计划，然后分析相关索引等是否合理。 通过语句查看执行计划的方法: SELECT id,parent_id,LPAD(' ',4*(LEVEL-1))||operation||' '||options||' '||object_name "Execution plan" ,cost,cardinality,bytes FROM ( SELECT p.* FROM v$sql_plan p,v$sql s WHERE p.address = s.ADDRESS AND p.hash_value = s.HASH_VALUE and p.hash_value = '&hash_value' ) CONNECT BY PRIOR id = parent_id START WITH id = 0; 查看，分析，优化索引等在这里就不再一一描述了。 6、实例的活动信息 这部分数据主要是从V$SYSSTAT表中统计出来的，一些条目的详细内容会在后面逐条标注。 Instance Activity Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14 Statistic Total per Second per Trans --------------------------------- ------------------ -------------- ------------ CPU used by this session 36,055 42.8 0.5 CPU used when call started 9,526 11.3 0.1 CR blocks created 9,509 11.3 0.1 DBWR buffers scanned 12,962 15.4 0.2 DBWR checkpoint buffers written 87,437 103.7 1.2 DBWR checkpoints 1 0.0 0.0 DBWR free buffers found 12,700 15.1 0.2 DBWR lru scans 116 0.1 0.0 DBWR make free requests 124 0.2 0.0 DBWR summed scan depth 12,962 15.4 0.2 DBWR transaction table writes 23 0.0 0.0 DBWR undo block writes 18,974 22.5 0.3 PX local messages recv'd 0 0.0 0.0 PX local messages sent 0 0.0 0.0 SQL*Net roundtrips to/from client 436,777 518.1 5.8 SQL*Net roundtrips to/from dblink 482 0.6 0.0 active txn count during cleanout 8,651 10.3 0.1 background checkpoints completed 2 0.0 0.0 background checkpoints started 1 0.0 0.0 branch node splits 6 0.0 0.0 buffer is not pinned count 2,170,225 2,574.4 28.7 buffer is pinned count 2,694,289 3,196.1 35.6 bytes received via SQL*Net from c 35,743,183 42,400.0 472.8 bytes received via SQL*Net from d 123,793 146.9 1.6 bytes sent via SQL*Net to client 25,187,619 29,878.6 333.1 bytes sent via SQL*Net to dblink 76,754 91.1 1.0 calls to get snapshot scn: kcmgss 1,533,555 1,819.2 20.3 calls to kcmgas 149,646 177.5 2.0 calls to kcmgcs 10,190 12.1 0.1 change write time 762 0.9 0.0 cleanout - number of ktugct calls 13,095 15.5 0.2 cluster key scan block gets 424 0.5 0.0 cluster key scans 202 0.2 0.0 commit cleanout failures: block l 1 0.0 0.0 commit cleanout failures: buffer 18 0.0 0.0 commit cleanout failures: callbac 63 0.1 0.0 commit cleanout failures: cannot 2,087 2.5 0.0 commit cleanouts 643,505 763.4 8.5 commit cleanouts successfully com 641,336 760.8 8.5 commit txn count during cleanout 35,188 41.7 0.5 consistent changes 63,943 75.9 0.9 consistent gets 16,616,758 19,711.5 219.8 由consistent gets，db block gets和physical reads这三个值，我们也可以计算得到buffer hit ratio，计算的公式如下： buffer hit ratio = 100*(1-physical reads /(consistent gets+ db block gets))，例如在这里，我们可以计算得到：buffer hit ratio =100*(1-26524/(16616758+2941398))= 99.86 consistent gets - examination 1,168,584 1,386.2 15.5 current blocks converted for CR 0 0.0 0.0 cursor authentications 2 0.0 0.0 data blocks consistent reads - un 63,873 75.8 0.8 db block changes 2,596,938 3,080.6 34.4 db block gets 2,941,398 3,489.2 38.9 deferred (CURRENT) block cleanout 130,783 155.1 1.7 dirty buffers inspected 166 0.2 0.0 脏数据从LRU列表中老化，A value here indicates that the DBWR is not keeping up。如果这个值大于0，就需要考虑增加DBWRs。 dirty buffers inspected: This is the number of dirty (modified) data buffers that were aged out on the LRU list. You may benefit by adding more DBWRs.If it is greater than 0, consider increasing the database writes. enqueue conversions 485 0.6 0.0 enqueue deadlocks 0 0.0 0.0 enqueue releases 318,825 378.2 4.2 enqueue requests 318,825 378.2 4.2 Instance Activity Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14 Statistic Total per Second per Trans --------------------------------- ------------------ -------------- ------------ enqueue waits 728 0.9 0.0 exchange deadlocks 30 0.0 0.0 execute count 1,004,280 1,191.3 13.3 free buffer inspected 188 0.2 0.0 这个值包含dirty，pinned，busy的buffer区域，如果free buffer inspected - dirty buffers inspected - buffer is pinned count的值还是比较大，表明不能被重用的内存块比较多，这将导致latch争用，需要增大buffer cache。 free buffer requested 116,422 138.1 1.5 hot buffers moved to head of LRU 17,750 21.1 0.2 immediate (CR) block cleanout app 1,916 2.3 0.0 immediate (CURRENT) block cleanou 81,385 96.5 1.1 index fast full scans (full) 0 0.0 0.0 index fetch by key 335,907 398.5 4.4 index scans kdiixs1 692,053 820.9 9.2 leaf node 90-10 splits 418 0.5 0.0 leaf node splits 1,941 2.3 0.0 logons cumulative 716 0.9 0.0 messages received 67,830 80.5 0.9 messages sent 67,830 80.5 0.9 no buffer to keep pinned count 0 0.0 0.0 no work - consistent read gets 14,240,381 16,892.5 188.4 opened cursors cumulative 84,306 100.0 1.1 parse count (failures) 6,074 7.2 0.1 parse count (hard) 6,090 7.2 0.1 parse count (total) 191,531 227.2 2.5 通过parse count (hard)和parse count (total)，可以计算soft parse率为： 100-100*(parse count (hard)/parse count (total)) =100-100*(1-6090/191531)=96.82 parse time cpu 44 0.1 0.0 parse time elapsed 635 0.8 0.0 physical reads 26,524 31.5 0.4 physical reads direct 288 0.3 0.0 physical writes 87,993 104.4 1.2 physical writes direct 128 0.2 0.0 physical writes non checkpoint 29,010 34.4 0.4 pinned buffers inspected 0 0.0 0.0 prefetch clients - default 0 0.0 0.0 prefetched blocks 16,550 19.6 0.2 prefetched blocks aged out before 0 0.0 0.0 process last non-idle time 0 0.0 0.0 recursive calls 1,398,277 1,658.7 18.5 recursive cpu usage 27,349 32.4 0.4 redo blocks written 749,639 889.3 9.9 redo buffer allocation retries 13 0.0 0.0 redo entries 1,343,828 1,594.1 17.8 redo log space requests 19 0.0 0.0 redo log space wait time 38 0.1 0.0 redo ordering marks 0 0.0 0.0 redo size 355,818,888 422,086.5 4,706.2 redo synch time 10,483 12.4 0.1 redo synch writes 74,372 88.2 1.0 redo wastage 15,765,096 18,701.2 208.5 redo write time 6,171 7.3 0.1 redo writer latching time 3 0.0 0.0 redo writes 67,055 79.5 0.9 rollback changes - undo records a 250 0.3 0.0 rows fetched via callback 310,070 367.8 4.1 session connect time 0 0.0 0.0 session cursor cache count 1,818 2.2 0.0 session cursor cache hits 168,798 200.2 2.2 session logical reads 19,558,052 23,200.5 258.7 session pga memory 549,909,680 652,324.7 7,273.4 Instance Activity Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14 Statistic Total per Second per Trans --------------------------------- ------------------ -------------- ------------ session pga memory max 1,185,992,768 1,406,871.6 15,686.5 session uga memory 3,015,076,014,672 ############## ############ session uga memory max 175,484,416 208,166.6 2,321.0 shared hash latch upgrades - no w 675,962 801.9 8.9 shared hash latch upgrades - wait 3,460 4.1 0.1 sorts (disks) 0 0 0 磁盘排序一般不能超过5％。如果超过5％，需要设置参数PGA_AGGREGATE_TARGET或者 SORT_AREA_SIZE，注意，这里SORT_AREA_SIZE是分配给每个用户的，PGA_AGGREGATE_TARGET则是针对所有的session的一个总数设置。 sorts (memory) 180,293 213.9 2.4 内存中的排序数量 sorts (rows) 511,574 606.9 6.8 summed dirty queue length 430 0.5 0.0 switch current to new buffer 59,534 70.6 0.8 table fetch by rowid 2,094,274 2,484.3 27.7 这是通过索引或者where rowid=语句来取得的行数，当然这个值越大越好。 table fetch continued row 408 0.5 0.0 这是发生行迁移的行。当行迁移的情况比较严重时，需要对这部分进行优化。 检查行迁移的方法： 1）运行$ORACLE_HOME/rdbms/admin/utlchain.sql 2）analyze table table_name list chained rows into CHAINED_ROWS 3）select * from CHAINED_ROWS where table_name='table_name'; 清除的方法： 方法1：create table table_name_tmp as select * from table_name where rowed in (select head_rowid from chained_rows); Delete from table_name where rowed in (select head_rowid from chained_rows); Insert into table_name select * from table_name_tmp; 方法2：create table table_name_tmp select * from table_name ; truncate table table_name insert into table_name select * from table_name_tmp 方法3：用exp工具导出表，然后删除这个表，最后用imp工具导入这表 方法4：alter table table_name move tablespace tablespace_name，然后再重新表的索引 上面的4种方法可以用以消除已经存在的行迁移现象，但是行迁移的产生很多情况下时由于PCT_FREE参数设置的太小所导致，所以需要调整PCT_FREE参数的值。 table scan blocks gotten 299,249 355.0 4.0 table scan rows gotten 1,912,851 2,269.1 25.3 table scans (long tables) 0 0.0 0.0 longtables就是表的大小超过buffer buffer* _SMALL_TABLE_THRESHOLD的表。如果一个数据库的大表扫描过多，那么db file scattered read等待事件可能同样非常显著。如果table scans (long tables)的per Trans值大于0，你可能需要增加适当的索引来优化你的SQL语句。 table scans (short tables) 143,830 170.6 1.9 short tables是指表的长度低于buffer chache 2％（2％是有隐含参数_SMALL_TABLE_THRESHOLD定义的，这个参数在oracle不同的版本中，有不同的含义。在9i和10g中，该参数值定义为2%，在8i中，该参数值为20个blocks，在v7中，该参数为5个blocks）的表。这些表将优先使用全表扫描。一般不使用索引。_SMALL_TABLE_THRESHOLD值的计算方法如下（9i,8K）： (db_cache_size/8192)*2％。 注意：_SMALL_TABLE_THRESHOLD参数修改是相当危险的操作。 transaction rollbacks 70 0.1 0.0 transaction tables consistent rea 0 0.0 0.0 transaction tables consistent rea 0 0.0 0.0 user calls 345,054 409.3 4.6 user commits 75,587 89.7 1.0 user rollbacks 19 0.0 0.0 workarea executions - optimal 247,121 293.1 3.3 write clones created in backgroun 0 0.0 0.0 write clones created in foregroun 25 0.0 0.0 7、I/O统计信息 下面两个报表是面向I/O的。通常，在这里期望在各设备上的读取和写入操作是均匀分布的。要找出什么文件可能非常“热”。一旦DBA了解了如何读取和写入这些数据，他们也许能够通过磁盘间更均匀的分配I/O而得到某些性能提升。 在这里主要关注Av Rd(ms)列 (reads per millisecond)的值，一般来说，大部分的磁盘系统的这个值都能调整到14ms以下，oracle认为该值超过20ms都是不必要的。如果该值超过1000ms，基本可以肯定存在I/O的性能瓶颈。如果在这一列上出现######，可能是你的系统存在严重的I/O问题，也可能是格式的显示问题。 当出现上面的问题，我们可以考虑以下的方法： 1）优化操作该表空间或者文件的相关的语句。 2）如果该表空间包含了索引，可以考虑压缩索引，是索引的分布空间减小，从而减小I/O。 3）将该表空间分散在多个逻辑卷中，平衡I/O的负载。 4）我们可以通过设置参数DB_FILE_MULTIBLOCK_READ_COUNT来调整读取的并行度，这将提高全表扫描的效率。但是也会带来一个问题，就是oracle会因此更多的使用全表扫描而放弃某些索引的使用。为解决这个问题，我们需要设置另外一个参数OPTIMIZER_INDEX_COST_ADJ=30（一般建议设置10－50）。 关于OPTIMIZER_INDEX_COST_ADJ＝n：该参数是一个百分比值，缺省值为100，可以理解为FULL SCAN COST/INDEX SCAN COST。当n%* INDEX SCAN COST 5）检查并调整I/O设备的性能。 Tablespace IO Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14 ->ordered by IOs (Reads + Writes) desc Tablespace ------------------------------ Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms) -------------- ------- ------ ------- ------------ -------- ---------- ------ ICD_DXH_IDX 3,869 5 8.6 1.0 36,701 44 1,180 0.1 ICD_DXH_DAT 2,572 3 9.7 1.0 16,545 20 1,076 0.2 UNDOTBS1 16 0 86.9 1.0 19,084 23 283 0.0 ICD_DXH_HISIDX 689 1 30.8 1.0 14,953 18 108 0.0 ICD_DXH_HISDAT 2,756 3 7.9 7.3 1,082 1 3 0.0 PERFSTAT 215 0 6.0 1.0 193 0 0 0.0 SYSTEM 55 0 11.5 5.0 17 0 717 0.1 INDX 1 0 40.0 1.0 1 0 0 0.0 TOOLS 1 0 40.0 1.0 1 0 0 0.0 USERS 1 0 40.0 1.0 1 0 0 0.0 ------------------------------------------------------------- File IO Stats for DB: ORA92 Instance: ora92 Snaps: 13 -14 ->ordered by Tablespace, File Tablespace Filename ------------------------ ---------------------------------------------------- Av Av Av Av Buffer Av Buf Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms) -------------- ------- ------ ------- ------------ -------- ---------- ------ ICD_DXH_DAT /dev/rlv_data001 377 0 9.4 1.0 1,640 2 321 0.2 /dev/rlv_data002 327 0 9.0 1.0 1,630 2 169 0.0 /dev/rlv_data003 313 0 10.0 1.0 1,718 2 87 0.0 /dev/rlv_data004 357 0 9.9 1.0 1,661 2 86 0.0 /dev/rlv_data005 400 0 11.5 1.0 1,627 2 128 0.2 /dev/rlv_data006 389 0 8.5 1.0 6,700 8 126 0.0 /dev/rlv_data007 409 0 9.6 1.0 1,569 2 159 0.7 8、Buffer Pool统计信息 这里将buffer poll细分，列举default、keep、recycle三种类型的buffer的详细情况。在这份报告中，我们的系统中只使用Default size的buffer pool。这里的3个waits统计，其实在前面的等待时间中已经包含，所以可以参考前面的描述。关于命中率也已经在前面讨论。 所以，其实这段信息不需要怎么关注。 Buffer Pool Statistics for DB: ORA92 Instance: ora92 Snaps: 13 -14 -> Standard block size Pools D: default, K: keep, R: recycle -> Default Pools for other block sizes: 2k, 4k, 8k, 16k, 32k Free Write Buffer Number of Cache Buffer Physical Physical Buffer Complete Busy P Buffers Hit % Gets Reads Writes Waits Waits Waits --- ---------- ----- ----------- ----------- ---------- ------- -------- ------ D 635,200 99.9 19,556,815 26,990 88,450 0 0 3,368 工作报告 摘要：随着行业利润逐渐理性化、成本不断上涨、输入性通货膨胀及同质产品竞争激烈，民营小企业发展受到前所未有的压力。此时，若不改变思维，必然导致利润空心化。于是在企业管理中实现效率与品质的合力，则显得异常重要。 关键词：品质、效率、基层管理、电子商务、无为、合力、质量体系 一关于理念与文化 1.1企业发展愿景 从本质上说，公司就是挣钱的机器，机构的设置、运作都应以产生利润为出发点。于是高层管理于企业发展应有一个明确的定位，如中长期规划、年度计划等。在现行管理学中亦流行“策略地图”一说。作为中小企业，可以借鉴之而制定“年度发展目标计划”。工作中有了蓝图，才会避免盲目性。在现代管理中常用的PDCA中，排在最前面的也就是Plan。 1.2高层管理的角色性 中小民营企业大多是合资或合伙企业，股权分散而股东较多。虽然存在股权划分一事，但又没有现代企业的股东机制。股东就是老板，于是股权催生了一种老板心理，而囿于传统观念，各个股东就纷纷有参与日常事物的心理需求。股东参与管理没错，但它参与管理方式应改变一下。如参与管理的老总本身意见不一，那下面就很难做事。其实做好一个老总，是需要有“近视眼”与“远视眼”。所谓的“远视”就是指在工作上要有预见性，如毛氏云：“坐在指挥台上，如果什么也看不见，就不能叫领导。坐在指挥台上，只看见地平线上已经出现的大量的普遍的东西，那是平平常常的，也不能算领导。只有当还没有出现大量的明显的东西的时候，当桅杆顶刚刚露出的时候，就能看出这是要发展成为大量的普遍的东西，并能掌握住它，这才叫领导。”做好规划与引导，就是高层应有的远视功能。凡事务必躬亲的，就不能让下面的管理者放手去做，人家就畏惧你忌惮你。故高层可以在管理上拥有点近视功能，一些部位工作可以让他人放手去做。大度点就是一定程度上的视而不见，即为近视。高层无需参与日常琐碎问题处理，与员工或下属保持一定距离，从而在员工与下属中产生一定神秘，接着神秘就带来了威严。员工或下属就不会随意地找高层，中层管理就有了威严。有了威严，工作与纪律就可以好好的推下去了。越级报告或越级处理都是管理上的大忌，员工随意进办公室去找高层，那中基层干部发挥不了作用。当然民营企业老总退出或放权须谨慎，一定要跳出“一抓严就死、一放就乱，最后不得不又亲力亲为”的窠臼。 二、管理现状与缺陷分析 2.1体系不全而制度跟不上。 虽实行了“职能制部门结构”，但大都松散而建制不全，没有串联起来。合理管理层次与管理幅度，缩编间接人员而放大一线员工比例，就可以扭变生产管理现状，降低时间成本与沉沫成本，从而提高效率与产能。为了以组织力与战斗力为标准去完善组织体系，就得设立大小流程与管理制度。创制了各个部门重要的大流程，就好比国家有了“京广铁路与107国道”，南北畅通；如再补上小流程，就如“京广铁路与107国道旁”的省道或县市路，于是无处不达了。有了流程，就得有制度去约束，就如有了道路就得有“交通规则”般。管理是德治、法治（制度）、人治的综合，尤其是现代企业中法治（制度）显得尤为重要。有了大小流程就等于人有了基本的骨架，而有了制度就是有了血肉。在各种制度中，有几个制度要先明确一下，那就是厂纪厂规、薪资结构制度、激励制度。这几个制度关系到员工们的士气与稳定。人大都分为“性本善”、“性本恶”两种，于是管理手法上须有软、硬两种。软的就是”劝诫、教育、褒奖与肯定”，硬的就是“惩戒、训斥”等。良好的激励机制与绩效管理是很必要的，否则员工的工作积极性与创造性是不可能激发或长久保持的。如目前奖惩都是不痛不痒的。员工的薪资完全可以和他的工作挂钩，表现好的、工作积极的、有创意的，其薪资就应当比别人高。我们可以把管理对象比作一条牛，只有拿稻草在前面引诱它，并以制度的牛绳栓住而牵引，才能让它往前迈而出成绩。我们可以在人力资源上有一定的容量和开放性，各个部门可以“适当”多养人（比实际需要的人数多一些，如“储备干部”），以利于比较、识别、留用资质潜力好、业绩能力强的人才，为将来计。采取奖惩结合、奖励为主的管理思想，做到由奖少罚多向奖惩平衡、奖多罚少的机制过度。 2.2被动式管理与士气缺乏 2020政府工作报告解读:九大任务如何完成 1深入推进“三去一降一补” 【原文】用改革的办法深入推进“三去一降一补”。要在巩固成果基础上，针对新情况新问题，完善政策措施，努力取得更大成效。 ·解读· 推进“三去一降一补”是供给侧结构性改革的重点任务之一，要做好“加法”“减法”和“乘法”。一是做“减法”。去产能、去 库存是结构性改革的重要任务，要坚持用市场化和法治化措施，释 优汰劣，把去产能与结构调整、转型升级和优化布局结合起来，统 筹谋划和推进。同时，金融、企业、地方政府的杠杆率还很高，要 坚持积极稳妥地去杠杆。 二是做“加法”，扩大有效的供给。不能简单地做“减法”，还要同时做好“加法”。我们现在很多东西还是短缺，很多产品和服 务质量升级的步伐落后于消费升级。要扩大有效的供给特别是公共 服务的供给，在供给端发力，满足老百姓不同层次的需求。 三是做“乘法”，发挥创新驱动的“乘数效应”。不能再依靠“人口红利”和“土地红利”来驱动供给侧改革，而要靠创新驱动、创新引领来深化供给侧结构性改革，要提高质量、提高效率。 2深化重要领域和关键环节改革 【原文】深化重要领域和关键环节改革。要全面深化各领域改革，加快推进基础性、关键性改革，增强内生发展动力。 ·解读· 今年的政府工作报告单独列出“深化重要领域和关键环节改革”，并将其作为一项重点任务来推进，这充分体现了今年工作任务中改 革的重要性，是一大亮点。事实上，这也与当前中国经济转型升级 需要完善体制机制的现实要求相符。 就具体内容来看，深化重要领域和关键环节改革以推进供给侧结构性改革为主线，呈现两大主要思路：一是理顺政府和市场的关系，推进政府职能转变，使市场在资源配置中起决定性作用和更好发挥 政府作用;二是完善基本经济制度，包括加强产权保护制度建设、深 入推进国企国资改革、抓好金融体制改革等，让权责利相统一，突 出强调责任约束，在追责、问责方面进行更为明确的规定，进而不 断完善体制机制建设。 通过切实有效的改革，社会生产力将会被进一步释放，中国经济转型升级也会得到更强的推动力。我们应继续坚持以改革促发展， 强化落实改革措施，在稳增长的基础上进一步推进改革。 3进一步释放国内需求潜力 【原文】进一步释放国内需求潜力。推动供给结构和需求结构相适应、消费升级和有效投资相促进、区域城乡发展相协调，增强内 需对经济增长的持久拉动作用。 ·解读· 在经济新常态下，靠投资和出口拉动的经济增长模式，要转向依靠消费和内需拉动，发展经济的注意力要注重“向内看”。 从外部来看，全球的经济增长下行压力大。过去5年贸易增速低于经济增长速度，很多加工贸易、制造业也已转移到海外。从内部 来看，中国老百姓收入增长，国内市场空间越来越大，中国正从 “世界工厂”变成“世界市场”。中国是全球第二大经济体，这一 庞大经济体再单纯依靠外部市场拉动已经不符合实际。 当前中国经济中许多问题是供给侧结构不合理，供给质量不高。政府工作报告中提出“供给结构和需求结构相适应”，就需要我们 提高产品的质量和科技含量，这是经济发展的潜力所在。区域发展 和城镇化抓住了当前经济发展的要害。不同地区经济发展差异性很大、互补性很强、回旋余地大，要分工利用好，协同提升，优化结构。而在城镇化过程中，农民变成新市民，则意味着消费需求、基 础设施建设的增长，这是经济发展的重要动力。 高考政治考点之《政府工作报告》解读 一、《经济生活》角度解读2020政府工作报告 1．保持人民币币值基本稳定，即对内保持物价总水平稳定，对外保持人民币汇率稳定，对人民生活安定、经济社会持续健康发展，对世界金融稳定、经济的发展具有重要意义。国务院总理李克强在2020年《政府工作报告》中指出，稳健的货币政策要更加灵活适度。综合运用降准降息、再贷款等手段，引导广义货币供应量和社会融资规模增速明显高于去年。2．收入是消费的基础和前提，要提高居民的生活水平，必须保持经济的稳定增长，增加居民收入。李克强在2020年《政府工作报告》中指出，拓展农民就业增收渠道。支持农民就近就业创业，扩大以工代赈规模，让返乡农民工能打工、有收入。 3．生产决定消费，生产决定消费的对象、方式、质量和水平，生产为消费创造动力，必须大力发展生产，满足消费。国务院总理李克强在2020年《政府工作报告》中指出，推动降低企业生产经营成本。降低工商业电价5%政策延长到今年年底。宽带和专线平均资费降低15%。减免国有房产租金，鼓励各类业主减免或缓收房租，并予政策支持。坚决整治涉企违规收费。 4．消费对生产具有重要的反作用，消费拉动经济增长、促进生产发展。国务院总理李克强在2020年《政府工作报告》中指出，我国内需潜力大，要深化供给侧结构性改革，突出民生导向，使提振消费与扩大投资有效结合、相互促进。推动消费回升。通过稳就业促增收保民生，提高居民消费意愿和能力。 5．国有经济是我国国民经济的支柱，它掌握着国家的经济命脉，在国民经济中起主导作用，发展、壮大国有经济，对于发挥社会主义制度的优越性，增强我国的经济实力、保障国家安全、保护生态环境、支持科技进步、发展战略性产业、提供公共服务，具有关键作用。国务院总理李克强在2020年《政府工作报告》中指出，完善国资监管体制，深化混合所有制改 全力打造“信息化中铝” ——中铝公司2012年信息化工作报告要点解读 【要点一】领导重视 中铝公司历届领导都高度重视信息化工作。公司成立之初就根据国家信息化发展的战略和要求进行信息化建设工作部署，搭建了公司信息化总体技术架构，公司信息化建设与管理起步早，技术起点高，为中铝公司信息化建设奠定了坚实基础。 新一届公司党组对信息化如何支撑公司战略转型和运营转型提出了明确要求。熊维平总经理亲自主持召开公司信息化工作领导小组会议，听取“十二五”信息化发展规划工作汇报，并出席专家论证会，对公司信息化工作作出重要指示。公司有关领导、总部各部门和各业务板块积极参加公司“十二五”信息化发展规划的访谈，对信息化工作提出了宝贵的指导意见。 在此基础上，公司集中各方智慧形成了《中国铝业公司“十二五”信息化发展规划》，明确了公司“十二五”信息化发展思路、目标、原则和任务，使公司信息化工作得到更好更快发展。 【要点二】成绩和进展 ； 目前，公司已形成覆盖主营业务的多个信息化业务应用系统。信息化系统作为公司信息流、资金流、物流的重要载体，日益成为公司生产经营的“神经”系统，日益成为公司管控和业务运作的重要支持平台，逐步形成了在我国有色金属行业信息化的领先优势，成为公司核心竞争力的重要组成部分。 一是清晰完善了公司信息化的顶层设计，逐步确立了信息化建设与管理应遵循的原则和思路，即“一个中铝，一个IT（系统）”、“五个统一”（即统一规划、统一标准、统一投资、统一建设、统一管理）。二是扎实推进了公司重点信息化项目建设。按照公司信息化建设与管理的“五统一”原则，公司高起点加快推进信息化系统建设，更好地服务于生产运营。三是ERP等公司重大信息化系统应用逐步深化。中国铝业从2004年开始，全面启动ERP系统建设，将人力资源、财务和营销这三大业务整合在一个统一平台上，实现生产经营的信息共享，全面推动管理创新。ERP 系统目前已经覆盖中国铝业本部及26家下属企业和10家托管企业，逐步形成了“铝矿山—氧化铝—电解铝—铝加工”较为完善的 ?单选题 ?1、2020年的政府工作报告指出，今年赤字率拟按（）%以上安排。（6.67分）?? A3.6 ? B4.6 ? C5.6 ? D6.6正确答案:A ? ?2、各级政府必须真正过紧日子，中央政府要带头，中央本级支出安排负增长，其中非急需非刚性支出压减（）%以上。（6.67分） ?? A50.0 ? B60.0 ? C70.0 ? D80.0正确答案:A ? ?3、2020年的政府工作报告指出，综合运用降准降息、再贷款等手段，引导广义货币供应量和社会融资规模增速明显（）去年。（6.67分） ? A低于 ?? B高于 ? C等于 ? D略小于正确答案:B ? ?4、2020年的政府工作报告指出，创新直达实体经济的货币政策工具，务必推动企业便利获得贷款，推动利率持续（）。（6.67分） ? A上行 ? B波动 ?? C下行 ? D稳定正确答案:C ? ?5、财政、货币和投资等政策要聚力支持（）。（6.67分） ?? A稳就业 ? B保民生 ? C促消费 ? D拉动市场、稳定增长正确答案:A ? ?6、各地要清理取消对就业的不合理限制，（）举措要应出尽出，拓岗位办法要能用尽用。（6.67分） ?? A稳就业 ? B保民生 ? C促消费 ? D拉动市场、稳定增长正确答案:A ? ?7、（）是最大的民生，对于一个家庭来说这是天大的事情。（6.67分）? A发展 ? B投资 ?? C就业 ? D资产正确答案:C ? ?8、本课指出，现在新业态蓬勃发展，大概有（）亿人就业，我们的零工经济也有2亿人就业。（6.67分） ?? A1.0 ? B2.0 ? C3.0 ? D4.0正确答案:A ?多选题 阜新市政府工作报告精神要点解读（全文） 各位代表： 现在，我代表阜新市人民政府向大会报告工作，请予审议，并请市政协各位委员和其他列席同志提出意见。 一、2014年工作回顾 过去一年，我市面临的经济形势严峻复杂，经济下行压力持续加大。在市委的正确领导下，在市人大、市政协的监督支持下，我们紧紧团结全市各族人民，坚持稳中求进工作总基调，全力以赴稳增长、促改革、调结构、惠民生，全市经济社会实现稳步发展，转型振兴迈出坚实步伐。 预计地区生产总值626亿元，增长4.5%;公共财政预算收入71.2亿元，增长1%;固定资产投资450亿元，剔除不可比因素增长2.3%;社会消费品零售总额259.4亿元，增长12.5%;实际利用外资2.5亿美元，增长21.9%;内资到位额310亿元，增长10%;出口总额3亿美元，增长12.5%;城镇和农村常住居民人均可支配收入分别达到21250元、10527元，分别增长10%。 ——项目建设取得较大进展。新开工投资五千万元以上项目261个，其中亿元以上114个;竣工投产248个。10亿元以上项目建设取得突破，总投资36亿元的鑫河LNG、15亿元的大金提质改造等项目开工，24亿元的兴隆CBD二期、12亿元的香港豪德商贸城一期等项目竣工，总投资23.4亿元的辉山系列项目部分投产。这些项目为带动投资、稳定增长提供了重要保障。合资合作取得新进展。广厦与宝钢合作、总投资40亿元的建筑产业基地，环宇与中航合作、总投资15亿元的液压支架项目开工;永生与徐工合作、总投资30亿元的整车装备，睿利与中冶合作的热镀铝生产线项目前期进展顺利。这些项目为提升产业水平、构筑竞争力提供了重要支撑。 招商取得新成效。以央企、民企、沪企辽宁行为契机，以京津冀、长三角、珠三角等地区为重点，深化招商合作。分别投资30亿元的天士力产业园、红星国际广场、国际金融港，15亿元的中天钛业、5亿元的东北特钢等92个亿元以上项目签约。这些项目为培育新增 十八大报告要点解读（整理版） 1.建成小康 【报告原文】：中国共产党第十八次全国代表大会，是在我国进入全面建成小康社会决定性阶段召开的一次十分重要的大会。大会的主题是：高举中国特色社会主义伟大旗帜，以邓小平理论、“三个代表”重要思想、科学发展观为指导，解放思想，改革开放，凝聚力量，攻坚克难，坚定不移沿着中国特色社会主义道路前进，为全面建成小康社会而奋斗。 【要点解读】：从“建设”到“建成”，这一字之变，是个质的飞跃；这一字之改的“含金量”很高，为我们扎扎实实迈向中华民族伟大复兴提供了一个看得见、摸得着、感受得到的阶段性目标，把全面建成惠及十几亿人口的更高水平小康社会美好前景，更加清晰地呈现在全国人民面前，必将极大激发全国人民的奋斗热情。 【报告原文】我们要准确判断重要战略机遇期内涵和条件的变化，全面把握机遇，沉着应对挑战，赢得主动，赢得优势，赢得未来，确保到二〇二〇年实现全面建成小康社会宏伟目标。 【要点解读】：“全面建设”到“全面建成”，一字之差标志着我国经济社会发展进入新阶段，十八大报告在党的十六大、十七大确立的全面建设小康社会目标上提出了新的要求：经济持续健康发展，人民民主不断扩大，文化软实力显著增强，人民生活水平全面提高，资源节约型、环境友好型社会建设取得重大进展。 “2020年实现全面建成小康社会，是全党和全国各族人民为之奋斗的共同目标。这一目标的提出，符合中国现实国情，符合科学发展观的要求，符合广大人民群众的意愿。”江苏省宿迁市委书记缪瑞林代表说。 云南省镇康县南伞镇红岩村党总支书记、村委会主任毕世华代表理解的“全面小康”就是丰衣足食、家家都在好房子里住、经济收入来源渠道多、有良好的公共服务和社会保障、有多余的钱投入基础设施建设。 过去十年，中国由世界第六大经济体成长为第二大经济体。这十年，中国城镇居民人均可支配收入和农村居民人均纯收入年均分别增长９．２％和８．１％，是新中国历史上居民收入增长最快的时期之一。当前，中国已经进入了全面建成小康社会的“决定性阶段”。 “13亿人的中国全面建成小康社会，这不仅是中国人的创举，也将是人类历史的奇迹。”内蒙古大学党委书记侯元代表说。 毕世华代表认为，要破解制约边疆民族地区奔小康的瓶颈，近要抓产业、远要抓教育，必须双管齐下。希望国家加大对边疆民族地区的支持力度，尤其在交 2018年全国两会政府工作报告的亮 点解读【详解】 是最新发布的《2018年全国两会政府工作报告的亮点解读【详解】》的详细范文参考文章，好的范文应该跟大家分享，为了方便大家的阅读。 3月5日上午9时，第十二届全国人民代表大会三次会议开幕，国务院总理李克强作政府工作报告。报告都有哪些亮点?经济观察报网为您逐个解读。 既反腐，也追究“为官不为” 报告原文：政府工作还存在不足，有些政策措施落实不到位。少数政府机关工作人员乱作为，一些腐败问题触目惊心，有的为官不为，在其位不谋其政，该办的事不办。我们要直面问题，安不忘危，治不忘乱，勇于担当，不辱 历史使命，不负人民重托。 经观说：十八大以来的反腐高压态势，已经根本改变了中国的官场生态，在风气明显好转的同时，一些政府和官员不作为、怠政懈政的现象明显抬头。治国先治官，应对新形势，亟需对症下药，在持续反腐之下，推动政府高效运转，追究官员“为政不为”的责任。 用政府权力“减法”换市场活力“乘法” 报告原文：大道至简，有权不可任性。各级政府都要建立简政放权、转变职能的有力推进机制，给企业松绑，为创业提供便利，营造公平竞争环境。所有行政审批事项都要简化程序，明确时限，用政府权力的“减法”，换取市场活力的“乘法”。 经观说：李克强总理推进简政放权的决心再次彰显无疑。工作总结这两年，政府一直在做减法，但“放的仍然不够”的声音始终存在，要全面激发市场经济的活力，政府转型的路还任重道 远。在放下不该管的事儿之外，政府应该管的事儿还有很多，厘清该管那些事儿，怎么管事儿，恐怕还要有一个建设的过程。 “有权不可任性” 报告原文：地方政府对应当放给市场和社会的权力，要彻底放、不截留，对上级下放的审批事项，要接得住、管得好。 经观说：近两年，随着简政放权的力度加大，一些地方和部门少数人表现出了“懒政”、“怠政”的情况，“不能为”、“不敢为”和“不愿为”这些观念仍然存在。经济结构调整转型后对干部的考核与以往不一样，原来是靠审批来管，简政放权之后怎么审，不审批了怎么办。总体来说，这是政府放权后如何管，怎样履行政府职责的问题。 7% 报告原文：今年经济社会发展的主要预期目标是：国内生产总值增长7%左右，居民消费价格涨幅3%左右， 2020北京市政府工作报告全文【解读】 从2020年1月开始，全国各地将进入地方两会时间。南方财富网小编特别整理了2020年北京两会时间、具体会议安排等相关内容，仅供参考! 会议时间：2020年1月14日开始 会议地点：北京 会议名称：北京市第十四届人民代表大会第五次会议 会议入口：2020北京两会 解读2020年北京市政府工作报告全文 位置最好自住房建工动力港在2020年元旦到来之前交房入住。360户业主将在新居过新春。北京晨报记者李木易/摄 2020年北京市政府工作报告民生 报告指出，2020年社会民生不断改善，但仍有许多群众不满意的地方，如优质公共服务供给总量不足与配置不均衡并存等。今年要继续落实首都城市战略定位，建设国际一流的和谐宜居之都，必须坚持以人民为中心，切实保障和改善民生。积极回应群众关切，扎实办好重要民生实事，确保首都和谐稳定。 2020年任务服务建百个一刻钟 实施提高生活性服务业品质行动计划，建设提升1000个便民商业网点，推动规范化、连锁化、品牌化发展。健全枢纽型社会组织工作体系，培育发展社区社会组织。深化街道社区管理体制改革，推进社区减负增效、社区协商，建设100个一刻钟社区服务圈。 就业 实现新增36万人 加强高校毕业生、就业困难群体和农村转移劳动力就业帮扶，做好相关企业职工分流安置，实现城镇新增就业36万人。 保障 实施精准救助 全面整合城乡居民基本医疗保险制度。实施精准救助，加大救急难力度，保障困难群众基本生活。积极做好留守儿童保障工作。 推进医养结合 深化残疾人社会保障和公共服务体系建设，推进残疾人小康进程。完善社会化养老服务体系，建设200家社区养老服务驿站，发展农村互助养老和志愿服务，深入推进医养结合。 住房 致力购租并举 把握住房的居住属性，以建立购租并举的住房制度为主要方向，以政府为主提供基本保障，以市场为主满足多层次需求，金融、财税、土地、市场监管等多措并举，探索建立符合国情市情、适应市场规律的基础性制度和长效机制。 促低价房供应 加大中低价位、中小套型普通商品住房供应比例，保障房建设筹集5万套、竣 关于2018政府工作报告，高考政治会怎么考？今天我们先来刷三个方面。 1 供给侧改革——三去一降一补 报告原文：深入推进供给侧结构性改革。坚持把发展经济着力点放在实体经济上，继续抓好“三去一降一补”，大力简政减税减费，不断优化营商环境，进一步激发市场主体活力，提升经济发展质量。 考点解读 涉及经济生活的考点：供给与需求关系及其影响、生产与消费的辩证关系、公司经营与发展、融资、财政的作用、税收的作用、市场调节与国家宏观调控、贯彻落实科学发展观，加快转变经济发展方式等。 涉及政治生活的考点：我国的国家性质、我国政府的职能和责任等。 涉及哲学的考点：意识的能动作用、一切从实际出发，实事求是、整体和部分的关系、系统优化方法、量变与质变关系原理及其方法论要求、具体问题具体分析、主次矛盾关系原理及其方法论要求、生产力和生产关系的相互作用及其矛盾运动等。 模拟高考 2018年3月5日，李克强总理在政府工作报告中强调，深入推进供给侧结构性改革。坚持把发展经济着力点放在实体经济上，继续抓好“三去一降一补”，大力简政减税减费，不断优化营商环境，进一步激发市场主体活力，提升经济发展质量。 上述供给侧改革的措施，体现了唯物辩证法的哪些道理？ 参考答案： ①掌握系统优化方法，注重系统内部结构的优化趋向。用改革的办法深入推进“三去一降一补”，实现整体功能的最大化。 ②重视量的积累，为实现事物的质变创造条件。要扎实有效去产能、积极稳妥去杠杆、多措并举降成本，努力取得更大成效。 ③坚持具体问题具体分析。要因城施策去库存，针对新情况新问题，完善政策措施。 ④着重把握主要矛盾，抓重点、抓中心、抓关键。要精准加力补短板。 (其他角度答题只要符合要求并合情合理即可。) 2 各领域改革 报告原文：全面深化财税、金融、社会、生态文明等体制改革，加快推进国企国资改革，加强产权保护制度建设，加快推进基础性、关键性改革，增强内生发展动力。 考点解读 （1）涉及经济生活考点：价格变动对经济生活的影响、国有经济及其主导作用、公司经营与发展、维护劳动者权益、商业银行和投资方式、我国多种分配方式并存、财政收入与支出及其作用、征税和纳税等。 （2）涉及政治生活考点：我国政府的职能等。 编号：TQC/K382 国务院工作报告解读完整 版 Daily description of the work content, achievements, and shortcomings, and finally put forward reasonable suggestions or new direction of efforts, so that the overall process does not deviate from the direction, continue to move towards the established goal. 【适用信息传递/研究经验/相互监督/自我提升等场景】 编写：________________________ 审核：________________________ 时间：________________________ 部门：________________________ 国务院工作报告解读完整版 下载说明：本报告资料适合用于日常描述工作内容，取得的成绩，以及不足，最后提出合理化的建议或者新的努力方向，使整体流程的进度信息实现快速共享，并使整体过程不偏离方向，继续朝既定的目标前行。可直接应用日常文档制作，也可以根据实际需要对其进行修改。 《报告》21个亮点解读 亮点1：7% 今年国内生产总值增长目标降至7%左右，是一个完全主动降速的过程，在对经济下行容忍度提高的同时，经济的“底线思维”更加清晰，就是要保证经济不出现系统性风险，也充分考虑到了就业需要和增长的可能，并且留有一定的弹性余地。经济在7%左右出现波动都是正常的，只要不出现过于猛烈的下行，就应该都是一个“合理”的增速。 2011年政府工作报告重要解读(包含5方面) 1、今年十项重点工作物价基本稳定居首 总理在政府工作报告中部署了2011年的十项重点工作。其中，位列第一的是被列为宏观调控首要任务的“稳定物价总水平”。 这十项重点工作包括： 一、保持物价总水平基本稳定。总理指出，物价问题涉及民生、关系全局、影响稳定。要努力消除输入性、结构性通胀因素的不利影响，消化要素成本上涨压力，正确引导市场预期，坚决抑制价格上涨势头。 二、进一步扩大内需特别是居民消费需求。总理强调，扩大内需是中国经济发展的长期战略方针和基本立足点，也是促进经济均衡发展的根本途径和内在要求。要积极扩大消费需求，大力优化投资结构。 三、巩固和加强农业基础地位。总理表示，要坚持把“三农”工作放在重中之重，在工业化、城镇化深入发展中同步推进农业现代化，巩固和发展农业农村好形势。 四、加快推进经济结构战略性调整。总理称，这是转变经济发展方式的主攻方向，要推动经济尽快走上内生增长、创新驱动的轨道。要调整优化产业结构，促进区域协调发展，积极稳妥推进城镇化，加强节能环保和生态建设，积极应对气候变化。 五、大力实施科教兴国战略和人才强国战略。总理称，要坚持优先发展教育，全面加强人才工作，大力推进科技创新。 六、加强社会建设和保障改善民生。总理表示，今年中央财政拟投入423亿元用于扶助和促进就业。合理调整收入分配关系。加快健全覆盖城乡居民的社会保障体系，坚定不移地搞好房地产市场调控。推进医药卫生事业改革发展。全面做好人口和计划生育工作。加强和创新社会管理。 七、大力加强文化建设。总理称，要更好地满足人民群众多层次多样化文化需求，发挥文化引导社会、教育人民、推动发展的功能，增强民族凝聚力和创造力。 八、深入推进重点领域改革。总理强调，要继续推进国有经济战略性调整，健全国有资本有进有退、合理流动机制。继续鼓励、支持和引导非公有制经济发展。 九、进一步提高对外开放水平。总理表示，要继续推动多哈回合谈判，反对各种形式的保护主义，促进国际经济秩序朝着更加公正、合理、共赢的方向发展。要切实转变外贸发展方式，推动对外投资和利用外资协调发展。 十、加强廉政建设和反腐败工作。总理强调，要加快解决反腐倡廉建设中的突出问题，扎实推进惩治和预防腐败体系建设，把查办大案要案作为反腐败的重要举措，同时更加注重制度建设 2、精简会议清理规范评比论坛庆典等活动 建设廉洁的政府是一项持久而又紧迫的任务，是人民的殷切期望。要加快解决反腐倡廉建设中的突出问题，扎实推进惩治和预防腐败体系建设，把查办大案要案作为反腐败的重要举措，同时更加注重制度建设。 一是认真治理政府工作人员以权谋私和渎职侵权问题。针对工程建设、土地使用权出让和矿产资源开发、国有产权交易、政府采购等重点领域存在的问题，加大查处违法违纪案件工作力度，坚决惩处腐败分子。 二是切实加强廉洁自律，认真贯彻执行《廉政准则》，落实领导干部收入、房产、投资以及配偶子女从业、移居国(境)外等情况定期报告制度，自觉接受监督。加强审计和监察工作。加大对行政机关领导干部和国有企业、事业单位负责人的监督力度。 2019年政府工作报告必学100条金句 1、快速崛起的新动能，正在重塑经济增长格局、深刻改变生产生活方式，成为中国创新发展的新标志。 2、改革全面发力、多点突破、纵深推进，重要领域和关键环节改革取得突破性进展。 3、确立区间调控的思路和方式，加强定向调控、相机调控、精准调控。 4、在财政收支矛盾较大情况下，着眼“放水养鱼”、增强后劲 5、大力发展新兴产业，改造提升传统产业，提高供给体系质量和效率。 6、安不忘危，兴不忘忧。 7、有能力有条件实现更高质量、更有效率、更加公平、更可持续的发展。 8、积极的财政政策取向不变，要聚力增效。 9、稳健的货币政策保持中性，要松紧适度。 10、坚持质量第一、效益优先，促进经济结构优化升级。 11、思想要再解放，改革要再深化，开放要再扩大。 12、排出时间表、路线图、优先序，确保风险隐患得到有效控制，确保脱贫攻坚任务全面完成，确保生态环境质量总体改善。 13、尽力而为、量力而行，把群众最关切最烦心的事一件一件解决好。 14、取消流量“漫游”费，移动网络流量资费年内至少降低30%，让群众和企业切实受益，为数字中国建设加油助力。 15、全面开展质量提升行动，推进与国际先进水平对标达标，弘扬工匠精神，来一场中国制造的品质革命。 16、全面实施“双随机、一公开”监管，决不允许假冒伪劣滋生蔓延，决不允许执法者吃拿卡要。 17、深入推进“互联网+政务服务”，使更多事项在网上办理，必须到现场办的也要力争做到“只进一扇门”、“最多跑一次”。 18、优化营商环境就是解放生产力、提高竞争力 19、要破障碍、去烦苛、筑坦途，为市场主体添活力，为人民群众增便利。 20、不合理的坚决取消，过高的坚决降下来，让企业轻装上阵、聚力发展。 21、有悖于激励创新的陈规旧章，要抓紧修改废止；有碍于释放创新活力的繁文缛节，要下决心砍掉。 22、我国拥有世界上规模最大的人力人才资源，这是创新发展的最大“富矿”。 23、集众智汇众力，一定能跑出中国创新“加速度”。 24、国有企业要通过改革创新，走在高质量发展前列。 25、激发和保护企业家精神，增强企业家信心，让民营企业在市场经济浪潮中尽显身手。 26、要用有力的产权保护、顺畅的要素流动，让市场活力和社会创造力竞相迸发。 27、全面实施绩效管理，使财政资金花得其所、用得安全。 28、深入推进教育、文化、体育等改革，充分释放社会领域巨大发展潜力。工作报告解读
2020政府工作报告解读：九大任务如何完成
高考政治考点之《政府工作报告》解读
某公司年度信息化工作报告要点解读
2020《政府工作报告》热点解读~课后测试
阜新市政府工作报告精神要点解读(全文)
十八大报告要点解读(整理版)
2018年全国两会政府工作报告的亮点解读【详解】
2020北京市政府工作报告全文【解读】
关于2018政府工作报告解读
国务院工作报告解读完整版
政府工作报告重要解读
2019年政府工作报告必学100条金句
相关主题
文本预览