oracle性能优化之awr分析

oracle性能优化之awr分析

作者:bingjava

 

最近某证券公司系统在业务期间系统运行缓慢,初步排查怀疑是数据库存在性能问题,因此导出了oracle的awr报告进行分析,在此进行记录。

导致系统的性能问题有很多,比如内存、cpu占用率过高,网络延迟、系统存储io瓶颈、还有程序方面的代码逻辑、性能低下的sql语句等等,这里主要从awr的角度说明如何通过awr的报告来定位问题。

一、awr报告分析及问题定位

DB Name 

DB Id 

Instance 

Inst num 

Release 

RAC 

Host 

**DB

1527139216 

**DB

1 

10.2.0.5.0

NO 

p3-**DB

 

Snap Id 

Snap Time 

Sessions 

Cursors/Session 

Begin Snap: 

16021 

01-Mar-16 10:00:34 

213 

2.4 

End Snap: 

16022 

01-Mar-16 11:00:36 

213 

2.3 

Elapsed: 

  

60.04 (mins) 

  

  

DB Time: 

  

176.32 (mins) 

  

  

关键项说明:

DB TIME:代表了此统计期间的数据库负载,是所有前台session花费在database调用上的总和时间(包括CPU时间、IO Time、和其他一系列非空闲等待时间)。如果 DB Time 接近于 Elapsed Time*cpu 数,表明数据库比较忙,cpu 负载也许比较大。这时很有可能是因为资源争用导致等待事件的结果,可以去 top 5 等待事件分析原因。

Operating System Statistics

Statistic 

Total 

BUSY_TIME 

1,037,128 

IDLE_TIME 

10,487,927 

IOWAIT_TIME 

19,061

NICE_TIME 

316 

SYS_TIME 

132,552 

USER_TIME 

882,792 

LOAD 

3 

RSRC_MGR_CPU_WAIT_TIME 

0 

VM_IN_BYTES 

1,274,466,304 

VM_OUT_BYTES 

2,174,697,472 

PHYSICAL_MEMORY_BYTES 

33,712,308,224 

NUM_CPUS 

32 

NUM_CPU_SOCKETS 

2 

 

 

从以上信息可知:

单数据库实例,非集群部署模式;2个物理cpu(NUM_CPU_SOCKETS=2),32个逻辑cpu(NUM_CPUS=32)。

cpu利用率为:DB Time /(Elapsed* NUM_CPUS)=176/(60*32) *100%=9.2%

cpu的负载处于正常水平。

Load Profile

 

Per Second 

Per Transaction 

Redo size: 

89,367.47 

21,227.40 

Logical reads: 

105,600.68 

25,083.26 

Block changes: 

458.93 

109.01 

Physical reads:

27,716.84 

6,583.56 

Physical writes: 

30.80 

7.32 

User calls: 

3,675.70 

873.09 

Parses: 

324.60 

77.10 

Hard parses: 

14.13 

3.36 

Sorts: 

44.47 

10.56 

Logons: 

1.69 

0.40 

Executes: 

340.07 

80.78 

Transactions: 

4.21 

  

 

% Blocks changed per Read: 

0.43 

Recursive Call %:

16.91 

Rollback per transaction %: 

0.09 

Rows per Sort: 

397.30 

 

Redosize:每秒产生的日志大小(单位字节),可标志数据变更频率,大的redosize往往对lgwr写日志,和arch归档造成I/O压力,也有可能造成logbuffer堵塞从而产生相关的等待事件。很繁忙的系统中日志生成量可能达到几百k,甚至几M。在Top 5 Timed Events中未发现log方面的等待事件,说明redo生成的频率属于正常范围。

 

Logical reads: 从内存中读取数据的次数(次数*块数),每秒钟逻辑读数据量:105,600.68*8k=825m

Physical reads:当从内存中未都到数据时则从硬盘上读取数据,每秒物理读数据量:27,716.84 *8k=216m

Physical reads / Logical reads=27,716.84/105,600.68=26%,有26%的逻辑读导致了物理io。因此此处的物理io可能是系统的性能瓶颈(具体需在后面的 top 5中进行分析)。

Instance Efficiency Percentages (Target 100%)

Buffer Nowait %: 

98.73 

Redo NoWait %: 

100.00 

Buffer Hit %:

73.77 

In-memory Sort %: 

100.00 

Library Hit %: 

89.85 

Soft Parse %: 

95.65 

Execute to Parse %: 

4.55 

Latch Hit %: 

96.92 

Parse CPU to Parse Elapsd %: 

95.60 

% Non-Parse CPU: 

96.41 

 

buffer hit:表示进程从内存中找到数据块的比率,监视这个值是否发生重大变化比这个 值本身更重要。对于一般的 OLTP 系统,通常应在 95%以上。否则应考虑加大 db_cache_size, 但是大量的非选择的索引也会造成该值很高(大量的 db file sequential read)。

Latch Hit:Latch是一种保护内存结构的锁,可以认为是SERVER进程获取访问内存数据结构的许可。要确保Latch Hit>99%,否则意味着Shared Pool latch争用,可能由于未共享的SQL,或者Library Cache太小,可使用绑定变更或调大Shared Pool解决。

Execute to Parse:是语句执行与分析的比例,如果要SQL重用率高,则这个比例会很高。该值越高表示一次解析后被重复执行的次数越多。

 

Parse CPU to Parse Elapsd:该指标反映了快照内解析CPU时间和总的解析时间的比值(Parse CPU Time/ Parse Elapsed Time); 若该指标水平很低,那么说明在整个解析过程中 实际在CPU上运算的时间很短,而主要的解析时间都耗费在各种其他非空闲的等待事件上了,此值越高越好。

 

Shared Pool Statistics

 

Begin 

End 

Memory Usage %:

56.42 

55.58 

% SQL with executions>1: 

54.12 

49.23 

% Memory for SQL w/exec>1: 

49.88 

48.29 

SQL with executions

代表了sql重复执行的比例,本报告中是54%,是比较低的,说明存在sql硬编码的情况,同时上面的Execute to Parse也只有4.55%,也说明了sql解析的重用率低。

内存利用率为55%左右,属于正常情况。

 

Top 5 Timed Events

业务11:00-12:00期间:

Event 

Waits 

Time(s) 

Avg Wait(ms) 

% Total Call Time 

Wait Class 

CPU time 

  

10,028 

  

94.8 

  

db file scattered read 

6,943,920 

644 

0 

6.1 

User I/O 

read by other session 

4,837,558 

578 

0 

5.5 

User I/O 

CSS initialization 

13 

65 

4,967 

.6 

Other 

db file sequential read

512,027 

58 

0 

.6 

User I/O 

业务15:00-16:00期间

Event 

Waits 

Time(s) 

Avg Wait(ms) 

% Total Call Time 

Wait Class 

CPU time 

  

2,569 

  

95.8 

  

SQL*Net more data to client 

1,150,806 

233 

0 

8.7 

Network 

db file scattered read 

1,381,500 

136 

0 

5.1 

User I/O 

CSS initialization

13 

63 

4,878 

2.4 

Other 

db file sequential read 

42,488 

30 

1 

1.1 

User I/O 

 

db file scattered read:

表明Oracle内核请求从磁盘读取多个数据块到buffer cache中,

这种情况通常显示与全表扫描相关的等待。当数据库进行全表扫时,基于性能的考虑, 数据会分散读入Buffer Cache。如果这个等待事件比较显著,可能说明对于某些全表扫描的表,没有创建索引或者没有创建合适的索引。

read by other session:

Oracle 操作的最小单位是块(Block),当对数据块做修改时,其他的会话将被阻止对这个数据块上的数据做修改,但是可以以一致性的方式读取这个数据块(from undo)。当前的用户修改完这个数据块后,将会立即释放掉加在这个数据块上的排他锁,这样另一个会话就可以继续修改它,这种加锁的机制叫Latch。当一个会话将数据块都到内存中时,其它的会话同时也请求了这个数据块,就导致被等待的会话出现read by other session。而当前会话一般是db file scattered read或db file sequential read。

从本次awr报告中都发现,db file scattered read、db file sequential read、read by other session这几个事件的等待次数很高,因此可以判断当前业务场景存在热点块竞争问题。

 

SQL*Net more data to client:

    当服务器端有太多的数据需要发给客户端时,可能会产生此等待事件,也可能由于网络问题导致服务器无法及时地将信息或者处理结果发送给客户端, 同样会产生这个等待。在15:00--16:00业务期间此等待事件相对较高,从SQL*Net看并不像应用程序(应用程序是JDBC Thin Client),可能是第三方的oracle监控程序导致的。

 

 

 

File IO Stats

Tablespace 

Filename 

Reads 

Av Reads/s 

Av Rd(ms) 

Av Blks/Rd 

Writes 

Av Writes/s 

Buffer Waits 

Av Buf Wt(ms) 

JSZ35_TBS 

tbs01.dbf

2,635,786 

732 

0.10 

14.88 

4,032 

1 

2,016,907 

0.12 

JSZ35_TBS 

tbs02.dbf

2,730,384 

758 

0.09 

12.89 

10,420 

3 

1,679,836 

0.12 

JSZ35_TBS 

tbs03.dbf

2,084,937 

579 

0.08 

12.19 

9,183 

3 

1,141,265 

0.13 

以上数据文件,平均每秒被读700多次,平均每秒读取的数据块为14块左右。

Tablespace IO Stats

Tablespace 

Reads 

Av Reads/s

Av Rd(ms) 

Av Blks/Rd 

Writes 

Av Writes/s 

Buffer Waits 

Av Buf Wt(ms) 

JSZ35_TBS 

1,420,317 

394 

0.11 

14.73 

9,502 

3 

113 

2.30 

 

Segments by Buffer Busy Waits

Owner 

Tablespace Name 

Object Name 

Subobject Name 

Obj. Type 

Buffer Busy Waits 

% of Capture 

JSZ35 

JSZ35_TBS

TF_SUBJECTPRICE_TMP 

  

TABLE 

30 

32.26 

JSZ35 

JSZ35_TBS 

IND_T_*LOG

  

INDEX 

21 

22.58 

JSZ35 

JSZ35_TBS 

PK_T_**_TMP

  

INDEX 

15 

16.13 

JSZ35 

JSZ35_TBS 

T_***HER

CHER_P2016 

TABLE PARTITION 

9 

9.68 

JSZ35 

JSZ35_TBS 

IND_T_***HER

  

INDEX 

7 

 

其它业务时间段:

Owner 

Tablespace Name 

Object Name 

Subobject Name 

Obj. Type 

Buffer Busy Waits 

% of Capture 

JSZ35 

JSZ35_TBS 

IND_T_*LOG

  

INDEX 

60 

68.18 

JSZ35 

JSZ35_TBS 

IND_T_***SED

  

INDEX 

20 

22.73 

 

JSZ35 

JSZ35_TBS 

TF_SUBJECTPRICE_TMP 

 

TABLE 

18 

17.65 

JSZ35 

JSZ35_TBS

IND_T_***HER

 

INDEX 

7 

6.86 

 

Segments by Physical Reads

Owner 

Tablespace Name 

Object Name 

Subobject Name 

Obj. Type 

Physical Reads 

%Total 

JSZ35 

JSZ35_TBS 

T_***NCE

ANCE_P2015 

TABLE PARTITION 

81,573,441 

81.70 

JSZ35 

JSZ35_TBS 

T_***NCE

ANCE_P2016 

TABLE PARTITION

12,884,029 

12.90 

JSZ35 

JSZ35_TBS 

T_***CE

RICE_P2016 

TABLE PARTITION 

3,471,341 

3.48 

热点数据块主要是T_***NCE、T_***CE引起。

数据块热点问题io等待的主要对象为:

T_***LOG、TF_SUBJECTPRICE_TMP、TS_PROCESSED、TF_SUBJECTPRICE_TMP、T_***NCE、T_***CE

可结合SQL ordered by CPU Time(最耗时的sql)、SQL ordered by Gets(逻辑读最多的sql)、SQL ordered by Reads(物理读最多的sql)来定位具体的sql语句。

 

二、问题总结及解决方式

    本报告期,系统的cpu、内存表现正常,造成系统性能问题的主要原因为物理读过多,产生io等待;同时由于相关业务表存在频繁的并发访问现象(逻辑读较多)且性能较差而导致了数据块竞争问题。逻辑读是消耗cpu的,而物理读是消耗io的,这也说明了系统的大部分时间都消耗在io等待上,所以cpu相对空闲。

优化方案主要包括应用层的优化和oracle数据库的优化:

    一、应用层的优化目标主要在于降低对数据库的访问频率、合理有效使用索引(合理有效使用索引,需通过对sql语句的执行计划进行分析和调优):

  1. T_***LOG可能存在较频繁的插入数据操作,可采用以下方式减少对数据库的提交操作:

将此表的单条insert的操作改为批量入库提交的方式(比例100条记录入库一次)。

  1. T_***_TMP可能存在读写混合的场景,需根据业务分析是否有优化的空间。
  1. T_***NCE、T_***CE、T_A***T,关于此表的相关访问应该是最需要优化的了,需优化的sql语句为(比如索引是否合理):

关键sql语句:SELECT /*+ LEADING ("A3" "A2" "A1") PQ_DISTRIBUTE ("A1", BROADCAST, NONE)USE_NL ("A1") FULL ("A1") PQ_DISTRIBUTE ("A2", BROADCAST, NONE)USE_NL ("A2") FULL ("A2") FULL ("A3") */ "A3"."FSETCODE", "A2"."FDATE", "A1"."FSETNAME", SUM(CASE WHEN "A3"."FACCTATTR" LIKE '??±????%' THEN "A2"."FENDBAL" ELSE 0 END ), SUM(CASE WHEN "A3"."FACCTATTR" LIKE '???±£??%' THEN "A2"."FENDBAL" ELSE 0 END ) FROM "T_A***T" "A3", "T_***NCE" "A2", "T_AS**T" "A1" WHERE "A3"."FACCTDETAIL"=1 AND "A2"."FDATE"=TO_DATE(TO_CHAR(:1), 'yyyy-mm-dd') AND ("A3"."FACCTATTR" LIKE '??±????%' OR "A3"."FACCTATTR" LIKE '???±£??') AND "A3"."FSETCODE"="A1"."FSETCODE" AND "A3"."FSETCODE"="A2"."FSETCODE" AND "A3"."FACCTCODE"="A2"."FACCTCODE" GROUP BY "A3"."FSETCODE", "A2"."FDATE", "A1"."FSETNAME"

select sum(NVL(fbacccredit, 0)) as fje from(select fsetcode, facctcode, fbacccredit from T_***NCE where fsetcode=:1 and fdate=:2 ) a left join T_A***T b on a.fsetcode = b.fsetcode and a.facctcode = b.facctcode where b.facctattr like :3 and b.facctdetail=1

select a.fdate, a.fsetcode, a.fzqdm, a.fhqssj, a.fhqpjj, a.fbjsj, a.fsjsj, a.fzdcj, a.fjyzt, a.fjysc, a.fzqlb, a.fsyqx, a.fdatasource, a.fyqfyfx, a.fgzjgly, a.ftpdate from T_***CE a where fsh = 1 and fdate = to_date('2016-02-29', 'yyyy-MM-dd') and a.fsetcode = 0 union select a.fdate, a.fsetcode, a.fzqdm, a.fhqssj, a.fhqpjj, a.fbjsj, a.fsjsj, a.fzdcj, a.fjyzt, a.fjysc, a.fzqlb, a.fsyqx, a.fdatasource, a.fyqfyfx, a.fgzjgly, a.ftpdate from (select fdate, fsetcode, fzqdm, fhqssj, fhqpjj, fbjsj, fsjsj, fzdcj, fjyzt, fjysc, fzqlb, fsyqx, fdatasource, fyqfyfx, fgzjgly, ftpdate, fsh from T_***CE where fzqlb = 'JJ') a right join (select FDate, FZqdm, fjysc From T_***CE where fsh = 1 and fdate = to_date('2016-02-26', 'yyyy-MM-dd') and fsetcode = 0 and fzqlb = 'JJ') b on b.FDate = a.FDate and a.FZqdm = b.FZqdm and a.fjysc = b.fjysc and a.fsh = 1 where fsetcode = 0 and a.fjysc = 'Y'

关键的sql语句:其中上面的第一条语句执行情况,SQL ordered by Elapsed Time

Elapsed Time (s) 

CPU Time (s) 

Executions 

Elap per Exec (s) 

% Total DB Time

SQL Id 

SQL Module 

SQL Text 

3,519 

3,601 

0 

  

33.26 

f089ggtmuxsnu

oracle@p3tgbmsdb1 (TNS V1-V3) 

SELECT /*+ LEADING… 

1,305 

1,086 

158 

8.26 

12.34 

7m0bfdfskwgcc

JDBC Thin Client 

select sum(…

该语句执行了3600秒(即整个快照期)都还未执行完成,该语句是三张表的关联统计查询,oracle自动对其进行并行查询,可能由于此三张表(T_A***T、T_***NCE、T_AS**T)的数据量较大,尤其是T_A***T的数据量较大时更是影响性能,采用并行查询后反而导致了对io的争用,降低了性能。

4、全表扫描问题

大表在一小时内发生了822次全表扫描,如果表的数据比较大则对性能有很大影响。小表每秒中有28次全表扫描,需重点优化以上3条sql语句。

table scans (direct read)

0 

0.00 

0.00 

table scans (long tables) 

822 

0.23 

0.07 

table scans (rowid ranges) 

0 

0.00 

0.00 

table scans (short tables) 

102,749 

28.52 

8.27 

total number of times SMON posted 

22 

0.01 

 

 

 

二、oracle优化

      1、合理设置DB_FILE_MULTIBLOCK_READ_COUNT,此参数控制在多数据块读时一次读入数据块的次数。适当增加这个参数大小,能够提高多数据块操作(如全表扫描)的IO效率。

2、可以考虑对以上热点表重建索引、分区表等方式来降低该数据段上的IO负荷,将历史数据进行分离(比如根据业务情况将2015年之前的数据转移到另外的备份库中)。

3、因Buffer Hit只有73%,可根据Buffer Pool Advisory调整buffer pool大小为:16g。

4、将频繁并发访问的表或数据移到另一数据块或者进行更大范围的分布(可以增大pctfree值 ,扩大数据分布,减少竞争)。

5、属于index block的表(如T_***SED、T_***_TMP),应该考虑重建索引、分割索引或使用反向键索引。关于反向键索引需根据sql语句查询特点进行有选择使用(如果在where中对索引列进行了范围搜索,则会导致该索引无效会进行全表扫描,反向键索引只对<>\=有效)。    

转载于:https://www.cnblogs.com/bingjava/p/5255760.html

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/430785.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

小米路由器怎么连接无盘服务器,播放器+服务器的方法瞬间玩转小米路由方法图文介绍...

“厨具”&#xff1a;小米路由及其外接硬盘、安卓手机、威动播放器(VidOn Player)、威动服务器(VidOn Server)“食材”&#xff1a;冰雪奇缘、生活大爆炸用两种方法将其“熬制”&#xff0c;时间短、内容丰富&#xff0c;“营养价值”相当的高。一、将小米路由作为NAS&#xff…

python json.loads namespace_python json.loads兼容单引号数据的方法

Python的json模块解析单引号数据会报错&#xff0c;示例如下>>> import json>>> data "{field1: 0, field2: hehehehe, field3: hahaha}">>> json.loads(data)Traceback (most recent call last):File “”, line 1, inFile “/usr/lib/…

@class #import辨析 #include

解析&#xff1a; 很多刚开始学习iOS开发的同学可能在看别人的代码的时候会发现有部分#import操作写在 .m 文件中&#xff0c;而 .h 文件仅仅使用class进行声明&#xff0c;不禁纳闷起来&#xff0c;为什么不直接把#import放到h文件中呢&#xff1f; 这是因为 .h 文件在修改后&…

修改数据包欺骗服务器,Fiddler协议捕获编辑工具与Session欺骗原理详解

今天Kitty主要与大家分享Fiddler抓包工具与协议捕获编辑工具来与大家讲解Session欺骗原理过程&#xff0c;咱们主要通过Fiddller协议捕获工具来对比HTTPWatch两款工具之间的差别&#xff0c;最主要的是我们可以通过捕获到的请求进行二次编辑重新发送给服务器&#xff0c;这中间…

统计源期刊目录_统计源期刊是什么意思

统计源期刊是什么意思&#xff1f;统计源期刊全称中国科技论文统计源期刊&#xff0c;也就是我们常说的科技核心期刊&#xff0c;科技核心期刊是我国核心期刊体系中的一类&#xff0c;在国内个人评职晋升、学术评估中占据着重要地位&#xff0c;统计源期刊也是根据期刊多方面指…

ajax 请求post和get,ajax请求get和post

ajax请求get和post 内容精选换一换正常返回值类型说明200OKGET、PUT、POST操作正常返回204No ContentDELETE操作正常返回异常返回值说明400 Bad Request服务器未能处理请求。401 Unauthorized被请求的页面需要用户名和密码。403 Forbidden对被请求页面的访问被禁止。404 Not Fo…

python requests 重试_我可以为requests.request设置最大重试次数吗?

这不仅会改变最大重试次数&#xff0c;而且还会启用回退策略&#xff0c;使所有http://地址在重试前睡眠一段时间(总共5次)&#xff1a;import requestsfrom urllib3.util.retry import Retryfrom requests.adapters import HTTPAdapters requests.Session()retries Retry(to…

产品专家Marty Cagan:不做仅仅会编码的人

Marty Cagan是享有世界声誉的产品管理专家&#xff0c;曾担任Netscape副总裁、eBay产品管理及设计高级副总裁。近日&#xff0c;记者在“PM-China首届产品经理高峰论坛”上对他做了专訪&#xff0c;请他分享自己的产品管理历程。 程序猿的工作 《程序猿》&#xff1a;据我所知。…

网页底部的版权信息_Shopify底部的版权信息(Powered by Shopify )如何删除

大多数新的Shopify商店所有者通常在一开始就遇到一个小问题。他们通常想摆脱商店页脚中的“Powered by Shopify”文本/链接。Shopify提供支持的含义是什么&#xff1f;Shopify是一个电子商务平台&#xff0c;可帮助创建和自定义电子商务商店。当您在此平台上创建商店时&#xf…

ftp 服务器 文件 连接 导出,ftp 服务器 文件 连接 导出

ftp 服务器 文件 连接 导出 内容精选换一换“数据导入”章节适用于MRS 3.x及后续版本。Loader是实现MRS与外部数据源如关系型数据库、SFTP服务器、FTP服务器之间交换数据和文件的ETL工具&#xff0c;支持将数据或文件从关系型数据库或文件系统导入到MRS系统中。Loader支持如下数…

自己的碎碎念

各位mmgg们&#xff0c;我是一个人见人爱&#xff0c;车载车爆胎的mm。 想知道我的年龄吗&#xff1f;我偷偷告诉你我正在学校和社会间徘徊&#xff08;年龄大了都不好意思明说了&#xff0c;没错&#xff0c;我就是娇羞&#xff09; 想知道我的职业吗&#xff1f;我想聪明的人…

python取绝对值数组_Python通用函数实现数组计算的方法

一.数组的运算数组的运算可以进行加减乘除&#xff0c;同时也可以将这些算数运算符进行任意的组合已达到效果。>>> xnp.arange(5)>>> xarray([0, 1, 2, 3, 4])>>> x5>>> xnp.arange(5)>>> x5array([5, 6, 7, 8, 9])>>> …

多个虚拟主机服务器,Windows多个虚拟主机服务器

Windows多个虚拟主机服务器 内容精选换一换迁移前&#xff0c;您需要设置目的端服务器。该目的端用来接收源端的数据&#xff0c;同时您也可以使用该目的端进行迁移测试和启动目的端。只有“迁移阶段”为“已就绪”时才可设置目的端。或单击“操作”列的“更多 > 设置目的端…

九度OJ #1437 To Fill or Not to Fil

题目描写叙述&#xff1a;With highways available, driving a car from Hangzhou to any other city is easy. But since the tank capacity of a car is limited, we have to find gas stations on the way from time to time. Different gas station may give different pri…

armv8 汇编 绝对地址赋值_详解汇编语言B和LDR指令与相对跳转和绝对跳转的关系...

[TOC]为什么要有相对跳转和绝对跳转&#xff1f;顺序执行&#xff1a;指令一条一条按照顺序往下执行&#xff0c;比如变量的定义和赋值都是按照顺序执行的。跳转执行&#xff1a;当指令执行到当前位置后跳转到其他位置执行。比如&#xff0c;在主函数中调用其他函数就是典型的跳…

BZOJ 4034: [HAOI2015]T2 树链剖分

4034: [HAOI2015]T2 Description 有一棵点数为 N 的树&#xff0c;以点 1 为根&#xff0c;且树点有边权。然后有 M 个 操作&#xff0c;分为三种&#xff1a;操作 1 &#xff1a;把某个节点 x 的点权增加 a 。操作 2 &#xff1a;把某个节点 x 为根的子树中所有点的点权都增加…

mysql把游标数据存入表中_mysql数据库怎么使用游标

存储过程完整代码.CREATE DEFINERrootlocalhost PROCEDURE cj_zongfen()BEGINDECLARE yw INT;#语文成绩DECLARE sx INT;#数学成绩DECLARE yy INT;#英语成绩DECLARE d INT;DECLARE nf BOOLEAN DEFAULT TRUE;DECLARE zongfen_cursor CURSOR FOR SELECT yuwen,shuxue,yingyu,cid …

yum安装ruby_centos 6.5 ruby环境安装

redis3.0以上支持集群&#xff0c;自带集群管理工具redis-trib.rb&#xff1b;在搭建集群前&#xff0c;安装ruby环境安装开发工具1、命令&#xff1a;yum groupinstall "Development tools"清理已安装过的2、命令&#xff1a;yum erase ruby ruby-libs ruby-mode ru…

mongodb3.0 性能測试报告 一

mongodb3.0 性能測试报告 一 mongodb3.0 性能測试报告 二 mongodb3.0 性能測试报告 三測试环境&#xff1a; 服务器&#xff1a;X86 pcserver 共6台 cpu&#xff1a; 单颗8核 内存&#xff1a;64G 磁盘&#xff1a; raid 10 操作系统 &#xff1a;centos 6.5 mongo…

db2 某个字段排序_MySQL、Oracle、DB2等数据库常规排序、自定义排序和按中文拼音字母排序...

MySQL常规排序、自定义排序和按中文拼音字母排序&#xff0c;在实际的SQL编写时&#xff0c;我们有时候需要对条件集合进行排序。下面给出3中比较常用的排序方式&#xff0c;mark一下1.常规排序ASC DESCASC 正序DESC倒叙-- 此处不用多讲2.自定义排序自定义排序是根据自己想要的…