Oracle 查询慢的原因总结
数据库慢查询问题的排查与性能优化实战
数据库慢查询问题的排查与性能优化实战数据库作为现代应用开发中不可或缺的基础设施,往往承载着大量重要的数据和业务逻辑。
然而,在实际应用中,我们常常遇到数据库查询变慢的问题。
这不仅会对用户体验造成不良影响,还可能导致系统性能下降。
在本篇文章中,我们将深入研究数据库慢查询问题,并介绍一些可行的解决方案和性能优化技巧。
首先,我们需要了解什么是数据库慢查询问题。
数据库查询速度变慢通常是由性能瓶颈引起的,可能是数据库服务器硬件配置不足、索引失效、查询语句设计不当等原因所致。
因此,解决数据库慢查询问题的关键在于找到性能瓶颈所在,并进行相应的优化。
为了排查数据库慢查询问题,我们可以采取以下步骤:1. 监控数据库性能:使用数据库性能监控工具,如MySQL的Performance Schema或Percona Toolkit,收集数据库的性能指标,例如查询执行时间、响应时间、锁的使用情况等。
通过对这些指标的分析,我们可以发现是否存在慢查询问题,并定位到具体的SQL语句。
2. 分析慢查询日志:数据库服务器通常会记录慢查询日志,其中包含执行时间超过阈值的查询语句。
我们可以通过分析慢查询日志来查找慢查询的原因。
例如,我们可以使用mysqldumpslow工具对慢查询日志进行解析,并找出执行时间最长的查询语句。
3. 检查索引使用情况:索引是提高数据库查询性能的关键。
我们需要检查数据库表的设计和索引是否合理,并确保查询语句使用了适当的索引。
如果索引失效或者没有使用到索引,可能导致查询性能下降。
4. 优化查询语句:当我们找到具体的慢查询语句后,可以通过优化查询语句的方式改善性能。
例如,可以重写查询语句,使用更好的查询计划,减少查询的数据量,或者使用分页查询来避免一次返回大量数据。
5. 数据库配置优化:数据库服务器的配置也会影响查询性能。
我们可以调整数据库的参数设置,如内存缓存大小、并发连接数等,以获得更好的性能表现。
在实施性能优化方案时,我们需要注意以下几点:1. 优化前进行性能基准测试:在进行性能优化之前,需要对当前系统的性能进行基准测试,以便评估优化效果。
影响Oracle查询效率的部分因素研究
1 3 基 于查 询效 率的表 组 织形式 选择 的 一般原 则 .
索引 扫描 (ne cn 。这些 情况 通常 有 : IdxSa ) 1 )表 未 做 s tts或 者 s tts陈 旧 , 致 tii asc t ii a sc 导 Oal判 断失 误 。 rce 2 )根 据该 表拥 有 的记 录数和 数据块 数 , 际上 实 全 表扫 描要 比索 引扫 描更 快 。 对 第 1种情 况 , 常见 的是 以下 这句 S L语 句 最 Q
tt s ii 之后 , sc 使用 的是 ID X( A TF L C N , N E F S U LS A )
只需 要 读取 4 0个 数据块 。 5
而第 2种情 况 就要 复杂得 多 。一般 情况 都认 为 索 引 比全 表扫 描快 , 比较 难 以理 解 什 么情 况 下 全 表 扫描要 比 索 引 扫 描 快 。 这 里 先 介 绍 一 下 O al rc e在
量, 进而提高查询效率 。
3 )如 果分 析 出表 的数 据 量 随着 应 用 而会 大 幅 增 涨 , 到 上 百 万 条 甚 至 更 多 条 , 以 考 虑 使 用 分 达 可
区表 的形式进 行组 织 , 据 表 中字 段 的不 同特 点 可 根
评估使用索引的代价 (o ) cs 时两个重要的数据 : F t C
烦, 表组 织形式 的选 择应遵 循 以下几 条பைடு நூலகம்原则 : 1 )如果表 的应 用趋 于正 常化 应用 , 没有 什 么特
oracle 查询慢的原因总结
查询速度慢的原因很多,常见如下几种:1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)2、I/O吞吐量小,形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足5、网络速度慢6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列10、查询语句不好,没有优化可以通过如下方法来优化查询:1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。
数据量(尺寸)越大,提高I/O越重要.2、纵向、横向分割表,减少表的尺寸(sp_spaceuse)3、升级硬件4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。
注意填充因子要适当(最好是使用默认值0)。
索引应该尽量小,使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段5、提高网速;6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。
配置虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行配置。
运行Microsoft SQL Server? 2000 时,可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。
如果另外安装了全文检索功能,并打算运行Microsoft 搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。
将SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍(虚拟内存大小设置的一半)。
7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。
使用并行还是串行程是MsSQL自动评估选择的。
数据库查询超时的原因分析与性能优化
数据库查询超时的原因分析与性能优化在现代应用程序和网站开发中,数据库是一个至关重要的组件。
然而,不可避免地会遇到数据库查询超时的情况,这会严重影响应用程序的性能和用户体验。
本文将深入探讨数据库查询超时的原因,并提供一些性能优化的建议。
首先,让我们来了解数据库查询超时的常见原因之一是数据库设计的问题。
如果数据库的表结构不合理或索引使用不当,查询将花费更长的时间来执行。
为了解决这个问题,我们应该对数据库进行优化。
首先,我们可以通过仔细分析应用程序的查询模式来优化表结构。
这包括合并和拆分表,使查询更加高效。
其次,我们应该在适当的字段上创建索引,以加快查询速度。
其次,数据库服务器的性能问题可能导致查询超时。
数据库服务器的资源不足,如内存、CPU和磁盘空间,都可能导致查询变慢甚至超时。
为了解决这个问题,我们可以考虑升级数据库服务器的硬件。
增加服务器的内存和CPU可以提高查询的性能。
此外,定期清理数据库中的垃圾数据和优化查询语句也是必不可少的操作。
第三,网络延迟是另一个常见的导致数据库查询超时的原因。
如果应用程序和数据库服务器之间的网络连接速度很慢,查询就会花费更长的时间。
为了解决网络延迟问题,我们可以考虑在数据库服务器和应用程序之间建立更快的网络连接,如使用高速互联网服务提供商或优化网络基础设施的性能。
此外,合理规划数据库服务器的位置,将其放置在与应用程序尽可能接近的地理位置也可以减少网络延迟。
另外,查询语句本身可能是导致查询超时的罪魁祸首。
如果查询语句写得不够好,比如使用了不必要的联接、子查询或者复杂的条件语句,查询就会变得低效。
为了优化查询语句的性能,我们应该使用适当的索引来加速查询。
此外,通过尽量减少查询返回的列数,可以减少数据的传输量,从而提高查询的性能。
最后,不可忽视的是数据库的事务管理。
长时间运行的事务可能会导致查询超时。
因此,我们应该尽量将事务的执行时间缩短到最小,并使用一些优化技术,如批量更新、延迟加载等来提高事务层面的性能。
数据库查询超时问题分析与解决
数据库查询超时问题分析与解决数据库是现代应用程序中不可或缺的一部分。
但是,在使用数据库时,经常会遇到查询超时的问题。
查询超时往往会导致应用程序响应变慢或者崩溃,给用户带来不好的用户体验。
本文将分析数据库查询超时的原因,并提供解决该问题的有效措施。
查询超时问题的原因可能有多种,如下所述:1. 数据量过大:当数据库中的数据量增加时,查询的执行时间会相应增加。
如果查询的时间超过了数据库服务器设定的超时时间,查询就会超时。
这种情况下,可以考虑优化查询语句,增加索引或者进行分表分库等方式来减少查询时间。
2. 索引问题:索引是加快查询速度的关键。
如果查询语句没有使用正确的索引,或者索引失效,就会导致查询超时。
可以使用数据库服务器提供的优化工具进行索引分析,找出需要添加或优化的索引。
3. 锁竞争:当多个并发连接同时操作数据库时,可能会导致锁竞争的问题。
如果某个查询需要获得一个正在被其他操作持有的锁,就会导致查询超时。
可以使用锁分析工具找出锁竞争的问题,并修改相应的代码逻辑或者调整锁策略,以避免查询超时。
4. 硬件资源不足:如果数据库服务器的硬件资源不足,如CPU、内存等,可能会导致查询超时。
可以通过优化数据库服务器的硬件配置或者分散数据库负载的方式来解决这个问题。
接下来,我们将提供一些解决数据库查询超时的有效措施:1. 优化查询语句:尽量避免使用复杂的查询语句。
可以使用EXPLAIN等工具来分析查询语句的性能,找出需要优化的地方。
在设计数据库表结构时,要注意避免多重嵌套的关联查询,尽量减少查询的字段数量。
2. 添加合适的索引:合理的索引设计对于提高数据库查询性能至关重要。
根据查询语句的不同,添加适当的索引可以减少查询的耗时。
但是,过多的索引也会增加数据库写操作的开销,所以需要根据实际情况进行权衡。
3. 缓存查询结果:对于查询结果稳定且数据更新频率低的查询,可以采用查询结果缓存的方式来加快查询速度。
使用缓存可以减少对数据库的访问次数,从而减少查询超时的风险。
oracle 查询慢的原因总结
查询速度慢的原因很多,常见如下几种:1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)2、I/O吞吐量小,形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足5、网络速度慢6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列10、查询语句不好,没有优化可以通过如下方法来优化查询:1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。
数据量(尺寸)越大,提高I/O越重要.2、纵向、横向分割表,减少表的尺寸(sp_spaceuse)3、升级硬件4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。
注意填充因子要适当(最好是使用默认值0)。
索引应该尽量小,使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段5、提高网速;6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。
配置虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行配置。
运行Microsoft SQL Server? 2000 时,可考虑将虚拟内存大小设置为计算机中安装的物理内存的 1.5 倍。
如果另外安装了全文检索功能,并打算运行Microsoft 搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配置为至少是计算机中安装的物理内存的 3 倍。
将SQL Server max server memory 服务器配置选项配置为物理内存的 1.5 倍(虚拟内存大小设置的一半)。
7、增加服务器CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。
使用并行还是串行程是MsSQL自动评估选择的。
Oracle查询表空间使用率很慢
Oracle查询表空间使⽤率很慢Oracle查询表空间使⽤率很慢问题描述执⾏查询表空间的语句,需要接近2min的时间才能执⾏完成。
以前也在其他客户的⽣产库遇到过⼀样的情况,当时是由于回收站的内容过多引起的。
不过这次的情况却不是这样,因为回收站的内容并不多。
调试分析⽼⽅法,设置statistics_level=all获取详细的执⾏情况,如下:20:32:05 SYS@anonymous>SELECT a.tablespace_name,20:32:052ROUND (a.bytes_alloc /1024/1024, 2) megs_alloc,20:32:053ROUND (NVL (b.bytes_free, 0) /1024/1024, 2) megs_free,20:32:054ROUND ((a.bytes_alloc - NVL (b.bytes_free, 0)) /1024/1024, 2 ) megs_used,20:32:055ROUND ((NVL (b.bytes_free, 0) / a.bytes_alloc) *100, 2) pct_free,20:32:056100-ROUND ((NVL (b.bytes_free, 0) / a.bytes_alloc) *100, 2) pct_used,20:32:057ROUND (maxbytes /1048576, 2) MAX20:32:058FROM20:32:059 (SELECT f.tablespace_name,20:32:0510SUM (f.BYTES) bytes_alloc,20:32:0511SUM (DECODE (f.autoextensible, 'YES', f.maxbytes, 'NO', f.BYTES ) ) maxbytes20:32:0512FROM dba_data_files f20:32:0513GROUP BY tablespace_name20:32:0514 ) a,20:32:0515 (SELECT f.tablespace_name,20:32:0516SUM (f.BYTES) bytes_free20:32:0517FROM dba_free_space f20:32:0518GROUP BY tablespace_name20:32:0519 ) b20:32:0520WHERE a.tablespace_name = b.tablespace_name(+)20:32:0521UNION ALL20:32:0522SELECT h.tablespace_name,20:32:0523ROUND (SUM (h.bytes_free + h.bytes_used) /1048576, 2) megs_alloc,20:32:0524ROUND ( SUM ((h.bytes_free + h.bytes_used) - NVL (p.bytes_used, 0)) /1048576, 2 ) megs_free,20:32:0525ROUND (SUM (NVL (p.bytes_used, 0)) /1048576, 2) megs_used,20:32:0526ROUND ( ( SUM ( (h.bytes_free + h.bytes_used) - NVL (p.bytes_used, 0) ) /SUM (h.bytes_used + h.bytes_free) ) *100, 2 ) pct_free,20:32:0527100-ROUND ( ( SUM ( (h.bytes_free + h.bytes_used) - NVL (p.bytes_used, 0) ) /SUM (h.bytes_used + h.bytes_free) ) *100, 2 ) pct_used,20:32:0528ROUND (SUM (f.maxbytes) /1048576, 2) MAX20:32:0529FROM SYS.v_$temp_space_header h,20:32:0530 SYS.v_$temp_extent_pool p,20:32:0531 dba_temp_files f20:32:0532WHERE p.file_id(+) = h.file_id20:32:0633AND p.tablespace_name(+) = h.tablespace_name20:32:0634AND f.file_id= h.file_id20:32:0635AND f.tablespace_name = h.tablespace_name20:32:0636GROUP BY h.tablespace_name20:32:0637ORDER BY1 ;TABLESPACE_NAME MEGS_ALLOC MEGS_FREE MEGS_USED PCT_FREE PCT_USED MAX------------------------------ ---------- ---------- ---------- ---------- ---------- ----------xxxxxxxxxxxxxxxx 409640197798.12 1.884096xxxxxxxxxxxxxxxx 81922283590927.8772.138192xxxxxxxxxxxxxxxx 2048111393554.3545.652048xxxxxxxxxxxxxxxx 2457616092848465.4834.5224576xxxxxxxxxxxxxxxx 40964095199.98 .024096xxxxxxxxxxxxxxxx 81928187599.94 .068192xxxxxxxxxxxxxxxx 4000337362784.3315.674000xxxxxxxxxxxxxxxx 54630434656119974363.4436.56546304xxxxxxxxxxxxxxxx 40962969112772.4927.514096xxxxxxxxxxxxxxxx 409640861099.76 .244096xxxxxxxxxxxxxxxx 81923047514537.1962.818192xxxxxxxxxxxxxxxx 2766087707819953027.8772.13276608xxxxxxxxxxxxxxxx 163848605777952.5247.4816384xxxxxxxxxxxxxxxx 40962944115271.8828.124096xxxxxxxxxxxxxxxx 1638435751280921.8278.1816384xxxxxxxxxxxxxxxx 40961074302226.2273.784096xxxxxxxxxxxxxxxx 409640712599.39 .614096xxxxxxxxxxxxxxxx 4096391518195.58 4.424096xxxxxxxxxxxxxxxx 163841598440097.56 2.4416384xxxxxxxxxxxxxxxx 327608390.8824369.1325.6174.3932767.98xxxxxxxxxxxxxxxx 536034.135325.88 .6499.3632767.98xxxxxxxxxxxxxxxx 40962946115071.9228.084096xxxxxxxxxxxxxxxx 409640524498.93 1.074096xxxxxxxxxxxxxxxx 2009613860623668.9731.0320096xxxxxxxxxxxxxxxx 1638413068331679.7620.2416384xxxxxxxxxxxxxxxx 2081924093316725919.6680.34208192xxxxxxxxxxxxxxxx 2009616143395380.3319.6720096xxxxxxxxxxxxxxxx 2048189815092.687.322048xxxxxxxxxxxxxxxx 2009616138395880.319.720096xxxxxxxxxxxxxxxx 68096133005479619.5380.4768096xxxxxxxxxxxxxxxx 819281791399.84 .168192xxxxxxxxxxxxxxxx 327673197179697.57 2.4332767.98xxxxxxxxxxxxxxxx 102402371.757868.2523.1676.8410240xxxxxxxxxxxxxxxx 103909292.251097.7589.4310.5732767.98xxxxxxxxxxxxxxxx 4356.25209.384146.88 4.8195.1932767.9835 rows selected.Elapsed: 00:01:54.6220:34:00 SYS@anonymous>select*from table(dbms_xplan.display_cursor(null,null,'allstats last'));PLAN_TABLE_OUTPUT------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------SQL_ID 8ks58zbpgra00, child number1-------------------------------------SELECT a.tablespace_name, ROUND (a.bytes_alloc /1024/1024, 2) megs_alloc, ROUND (NVL (b.bytes_free, 0) /1024/1024, 2)megs_free, ROUND ((a.bytes_alloc - NVL (b.bytes_free, 0)) /1024/1024, 2 ) megs_used, ROUND ((NVL (b.bytes_free, 0) /a.bytes_alloc) *100, 2) pct_free, 100-ROUND ((NVL (b.bytes_free, 0) / a.bytes_alloc) *100, 2) pct_used,ROUND (maxbytes /1048576, 2) MAX FROM (SELECTf.tablespace_name, SUM (f.BYTES) bytes_alloc, SUM (DECODE(f.autoextensible, 'YES', f.maxbytes, 'NO', f.BYTES ) ) maxbytes FROMdba_data_files f GROUP BY tablespace_name ) a, (SELECTf.tablespace_name, SUM (f.BYTES) bytes_free FROM dba_free_space fGROUP BY tablespace_name ) b WHERE a.tablespace_name =b.tablespace_name(+) UNION ALL SELECT h.tablespace_name, ROUND (SUM(h.bytes_free + h.bytes_used) /1048576, 2) megs_alloc,ROUND ( SUM ((h.bytes_free + h.bytes_used) - NVL (p.bPlan hash value: 2506036241------------------------------------------------------------------------------------------------------------------------------------------------------------| Id | Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | OMem | 1Mem | Used-Mem | ------------------------------------------------------------------------------------------------------------------------------------------------------------|0|SELECT STATEMENT ||1||35|00:01:54.53|53354|4865|||||1| SORT ORDER BY||1|3|35|00:01:54.53|53354|4865|4096|4096|4096 (0)||2|UNION-ALL||1||35|00:01:54.53|53354|4865|||||*3| HASH JOIN OUTER||1|2|34|00:01:54.18|53310|4865| 1229K| 1229K| 1243K (0)||4|VIEW||1|2|34|00:00:00.66|444|0|||||5| HASH GROUP BY||1|2|34|00:00:00.66|444|0| 941K| 941K| 1349K (0)||6|VIEW| DBA_DATA_FILES |1|2|108|00:00:00.65|444|0|||||7|UNION-ALL||1||108|00:00:00.65|444|0|||||8| NESTED LOOPS ||1|1|0|00:00:00.57|112|0|||||9| NESTED LOOPS ||1|1|0|00:00:00.57|112|0|||||10| NESTED LOOPS ||1|1|0|00:00:00.57|112|0|||||*11| FIXED TABLE FULL| X$KCCFN |1|1|108|00:00:00.57|0|0|||||*12|TABLE ACCESS BY INDEX ROWID|FILE$ |108|1|0|00:00:00.01|112|0|||||*13|INDEX UNIQUE SCAN | I_FILE1 |108|1|108|00:00:00.01|4|0|||||*14| FIXED TABLE FIXED INDEX| X$KCCFE (ind:1) |0|1|0|00:00:00.01|0|0|||||15|TABLE ACCESS CLUSTER | TS$ |0|1|0|00:00:00.01|0|0|||||*16|INDEX UNIQUE SCAN | I_TS# |0|1|0|00:00:00.01|0|0|||||17| NESTED LOOPS ||1|1|108|00:00:00.08|332|0|||||18| NESTED LOOPS ||1|1|108|00:00:00.08|220|0|||||19| NESTED LOOPS ||1|1|108|00:00:00.01|220|0|||||20| NESTED LOOPS ||1|1|108|00:00:00.01|108|0|||||*21| FIXED TABLE FULL| X$KCCFN |1|1|108|00:00:00.01|0|0|||||*22| FIXED TABLE FIXED INDEX| X$KTFBHC (ind:1) |108|1|108|00:00:00.01|108|0|||||*23|TABLE ACCESS BY INDEX ROWID|FILE$ |108|1|108|00:00:00.01|112|0|||||*24|INDEX UNIQUE SCAN | I_FILE1 |108|1|108|00:00:00.01|4|0|||||*25| FIXED TABLE FIXED INDEX| X$KCCFE (ind:1) |108|1|108|00:00:00.08|0|0|||||26|TABLE ACCESS CLUSTER | TS$ |108|1|108|00:00:00.01|112|0|||||*27|INDEX UNIQUE SCAN | I_TS# |108|1|108|00:00:00.01|4|0|||||28|VIEW||1|31|34|00:01:53.52|52866|4865|||||29| HASH GROUP BY||1|31|34|00:01:53.52|52866|4865| 9291K| 2834K| 1346K (0)||30|VIEW| DBA_FREE_SPACE |1|140| 100K|00:01:53.50|52866|4865|||||31|UNION-ALL||1|| 100K|00:01:53.48|52866|4865|||||32| NESTED LOOPS ||1|1|0|00:00:00.01|38|0|||||33| NESTED LOOPS ||1|1|0|00:00:00.01|38|0|||||34|TABLE ACCESS FULL| FET$ |1|1|0|00:00:00.01|38|0|||||*35|TABLE ACCESS CLUSTER | TS$ |0|1|0|00:00:00.01|0|0|||||*36|INDEX UNIQUE SCAN | I_TS# |0|1|0|00:00:00.01|0|0|||||*37|INDEX UNIQUE SCAN | I_FILE2 |0|1|0|00:00:00.01|0|0|||||38| NESTED LOOPS ||1|88|84440|00:00:00.15|394|0|||||39| NESTED LOOPS ||1|88|84440|00:00:00.06|390|0|||||*40|TABLE ACCESS FULL| TS$ |1|31|34|00:00:00.01|38|0|||||*41| FIXED TABLE FIXED INDEX| X$KTFBFE (ind:1) |34|3|84440|00:00:00.05|352|0|||||*42|INDEX UNIQUE SCAN | I_FILE2 |84440|1|84440|00:00:00.06|4|0|||||*43| HASH JOIN||1|50|16133|00:01:53.30|52396|4865| 2297K| 2297K| 2426K (0)||44| NESTED LOOPS ||1|50|16133|00:01:53.29|52358|4865|||||*45| HASH JOIN||1|808|16133|00:01:53.26|52354|4865| 1753K| 1753K| 1511K (0)||*46|TABLE ACCESS FULL| RECYCLEBIN$ |1|152|191|00:00:00.01|4|0|||||47| FIXED TABLE FULL| X$KTFBUE |1| 100K| 723K|00:01:52.95|52350|4865|||||*48|INDEX UNIQUE SCAN | I_FILE2 |16133|1|16133|00:00:00.01|4|0|||||*49|TABLE ACCESS FULL| TS$ |1|31|34|00:00:00.01|38|0|||||50| NESTED LOOPS ||1|1|0|00:00:00.01|38|0|||||51| NESTED LOOPS ||1|1|0|00:00:00.01|38|0|||||52| MERGE JOIN CARTESIAN ||1|425|0|00:00:00.01|38|0|||||*53|TABLE ACCESS FULL| TS$ |1|3|0|00:00:00.01|38|0|||||54| BUFFER SORT ||0|152|0|00:00:00.01|0|0|73728|73728|||*55|TABLE ACCESS FULL| RECYCLEBIN$ |0|152|0|00:00:00.01|0|0|||||56|TABLE ACCESS CLUSTER | UET$ |0|1|0|00:00:00.01|0|0|||||*57|INDEX UNIQUE SCAN | I_FILE#_BLOCK# |0|1|0|00:00:00.01|0|0|||||*58|INDEX UNIQUE SCAN | I_FILE2 |0|1|0|00:00:00.01|0|0|||||59| HASH GROUP BY||1|1|1|00:00:00.35|44|0| 856K| 856K| 463K (0)||60| NESTED LOOPS OUTER||1|1|1|00:00:00.35|44|0|||||*61| HASH JOIN||1|1|1|00:00:00.35|42|0| 1281K| 1281K| 402K (0)||62| NESTED LOOPS ||1|1|1|00:00:00.35|3|0|||||63| NESTED LOOPS ||1|1|1|00:00:00.35|1|0|||||64| NESTED LOOPS ||1|1|1|00:00:00.35|0|0|||||*65| FIXED TABLE FULL| X$KCCFN |1|1|1|00:00:00.34|0|0|||||*66| FIXED TABLE FIXED INDEX| X$KCCTF (ind:1) |1|1|1|00:00:00.01|0|0|||||*67| FIXED TABLE FIXED INDEX| X$KTFTHC (ind:1) |1|1|1|00:00:00.01|1|0|||||68|TABLE ACCESS CLUSTER | TS$ |1|1|1|00:00:00.01|2|0|||||*69|INDEX UNIQUE SCAN | I_TS# |1|1|1|00:00:00.01|1|0|||||70|VIEW| V_$TEMP_SPACE_HEADER |1|1|1|00:00:00.01|39|0|||||71| NESTED LOOPS ||1|1|1|00:00:00.01|39|0|||||*72|TABLE ACCESS FULL| TS$ |1|1|1|00:00:00.01|38|0|||||*73| FIXED TABLE FIXED INDEX| X$KTFTHC (ind:2) |1|1|1|00:00:00.01|1|0|||||*74|VIEW PUSHED PREDICATE | V_$TEMP_EXTENT_POOL |1|1|1|00:00:00.01|2|0|||| |75| NESTED LOOPS ||1|1|1|00:00:00.01|2|0|||||*76|TABLE ACCESS BY INDEX ROWID | TS$ |1|1|1|00:00:00.01|2|0|||||*77|INDEX UNIQUE SCAN | I_TS1 |1|1|1|00:00:00.01|1|0|||||*78| FIXED TABLE FIXED INDEX| X$KTSTFC (ind:1) |1|1|1|00:00:00.01|0|0||||------------------------------------------------------------------------------------------------------------------------------------------------------------Predicate Information (identified by operation id):---------------------------------------------------3- access("A"."TABLESPACE_NAME"="B"."TABLESPACE_NAME")11- filter(("FNNAM" IS NOT NULL AND "FNTYP"=4AND "INST_ID"=USERENV('INSTANCE') AND BITAND("FNFLG",4)<>4))12- filter("F"."SPARE1" IS NULL)13- access("FNFNO"="F"."FILE#")14- filter("FE"."FENUM"="F"."FILE#")16- access("F"."TS#"="TS"."TS#")21- filter(("FNNAM" IS NOT NULL AND "FNTYP"=4AND "INST_ID"=USERENV('INSTANCE') AND BITAND("FNFLG",4)<>4))22- filter("FNFNO"="HC"."KTFBHCAFNO")23- filter("F"."SPARE1" IS NOT NULL)24- access("FNFNO"="F"."FILE#")25- filter("FE"."FENUM"="F"."FILE#")27- access("HC"."KTFBHCTSN"="TS"."TS#")35- filter("TS"."BITMAPPED"=0)36- access("TS"."TS#"="F"."TS#")37- access("F"."TS#"="FI"."TS#" AND "F"."FILE#"="FI"."RELFILE#")40- filter(("TS"."BITMAPPED"<>0AND "TS"."CONTENTS$"=0AND INTERNAL_FUNCTION("TS"."ONLINE$")))41- filter("TS"."TS#"="F"."KTFBFETSN")42- access("F"."KTFBFETSN"="FI"."TS#" AND "F"."KTFBFEFNO"="FI"."RELFILE#")43- access("TS"."TS#"="RB"."TS#")45- access("U"."KTFBUESEGTSN"="RB"."TS#" AND "U"."KTFBUESEGFNO"="RB"."FILE#" AND "U"."KTFBUESEGBNO"="RB"."BLOCK#") 46- filter(("RB"."TS#" IS NOT NULL AND "RB"."FILE#" IS NOT NULL AND "RB"."BLOCK#" IS NOT NULL))48- access("RB"."TS#"="FI"."TS#" AND "U"."KTFBUEFNO"="FI"."RELFILE#")49- filter(("TS"."BITMAPPED"<>0AND "TS"."CONTENTS$"=0AND INTERNAL_FUNCTION("TS"."ONLINE$")))53- filter("TS"."BITMAPPED"=0)55- filter(("RB"."TS#" IS NOT NULL AND "RB"."FILE#" IS NOT NULL AND "RB"."BLOCK#" IS NOT NULL))57- access("U"."TS#"="RB"."TS#" AND "U"."SEGFILE#"="RB"."FILE#" AND "U"."SEGBLOCK#"="RB"."BLOCK#")filter("TS"."TS#"="U"."TS#")58- access("U"."TS#"="FI"."TS#" AND "U"."SEGFILE#"="FI"."RELFILE#")61- access("HC"."KTFTHCTFNO"="H"."FILE_ID" AND "TS"."NAME"="H"."TABLESPACE_NAME")65- filter(("V"."FNNAM" IS NOT NULL AND "V"."FNTYP"=7))66- filter(("TF"."TFDUP"<>0AND BITAND("TF"."TFSTA",32)<>32AND "V"."FNFNO"="TF"."TFNUM" AND "TF"."TFFNH"="V"."FNNUM"))67- filter("V"."FNFNO"="HC"."KTFTHCTFNO")69- access("HC"."KTFTHCTSN"="TS"."TS#")72- filter(("TS"."CONTENTS$"=1AND "TS"."BITMAPPED"<>0AND "TS"."ONLINE$"=1))73- filter(("HC"."KTFTHCCVAL"=0AND "HC"."INST_ID"=USERENV('INSTANCE') AND "TS"."TS#"="HC"."KTFTHCTSN"))74- filter("P"."FILE_ID"="H"."FILE_ID")76- filter(("TS"."CONTENTS$"=1AND "TS"."BITMAPPED"<>0AND "TS"."ONLINE$"=1))77- access("TS"."NAME"="H"."TABLESPACE_NAME")78- filter(("FC"."INST_ID"=USERENV('INSTANCE') AND "TS"."TS#"="FC"."KTSTFCTSN"))147 rows selected.Elapsed: 00:00:00.08可以发现,慢的步骤在于对表X$KTFBUE的全表扫描,这个问题也引起了另外⼀个问题,可以看我另外⼀篇博⽂->。
OracleRAC11gr2性能调优解决查询慢问题
知也无涯Oracle RAC 11g r2查询太慢---------------------------------------------------Oracle RAC 11g r2查询太慢Problem Description---------------------------------------------------Redhat 5 双机测试1:双实例,ASM磁盘组包含3个磁盘(SAN)。
在其中一个实例中执行:SELECT c.operaccount || ':' || c.PASSWORD || '@' || a.PATH,a.dll, a.description, '1.gif'FROM hcs2000.dllnames a, hcs2000.operdllnames b, hcs2000.operaccount c WHERE a.dllnameid = b.dllnameidAND b.operid = c.operidAND upper(c.operaccount) = USERORDER BY a.dllnameid;第一次查询,25秒。
第二次查询,3秒。
第三次查询,1.6秒。
过10分钟后查询,26秒。
测试2:在其中一台主机上创建基于ASM磁盘组的单个实例,第一次查询,14秒。
第二次查询,3秒。
第三次查询,0.7秒。
第四次查询,3.5秒。
测试3:在其中一台主机上创建基于文件系统的单个实例,第一次查询,5秒。
第二次查询,2.2秒。
第三次查询,2.1秒。
测试4:在PC的VMware虚拟机里面单实例查询,只需0.001秒或0秒。
测试1中的查询太慢了,请问怎么查看问题原因,如何调优?Dear customer,请您执行以下动作:如果可以,请在您提到的4个场景下都生成以下文件,并请添加您的说明后,作为附件更新到SR上:ACTION PLAN-----------------------1. Please generate 10046 trace for your sql:SQL>connect username/passwordSQL>alter session set timed_statistics = true;SQL>alter session set statistics_level=all;SQL>alter session set max_dump_ = unlimited;SQL>alter session set events '10046 trace name context forever, level 12';SQL><Run your SQL here;>SQL>alter session set events '10046 trace name context off';2.Format your 10046 trace file:$tkprof <trace file> <output file>例如生成的文件应该是在您的udump路径下面。
OracleSQL执行缓慢的原因以及解决方案
OracleSQL执行缓慢的原因以及解决方案第一篇:Oracle SQL执行缓慢的原因以及解决方案Oracle SQL执行缓慢的原因以及解决方案Oracle SQL执行缓慢的原因的分析,如果Oracle数据库中的某张表的相关数据已是2亿多时,同时此表也创建了相关的4个独立的相关索引。
由于业务方面的需要,每天需分两次向此表中插入300万条记录。
由于数据量大,每次插入耗时3个小时以上,严重影响效率。
因此,修改了系统的算法,将此表中只存储当天新增记录。
将此表truncate后,第二天执行对此表的update操作时,非常耗时。
表中有2亿多条数据的时候,此Oracle sql语句耗时59秒;表中有300万条数据的时候,此Oracle sql语句耗时几个小时。
咨询DBA后,得出结论,需重建索引。
重建后,6秒完成此操作。
但第三天问题依然出现。
DBA正在查找原因。
难道每次truncate表,都需要重建索引?对于这个问题,DBA也没有给出合理的解释,推测主要原因是Oracle复杂的查询优化算法。
最终,DBA给出的解决方案:1.truncate table....2.drop index.....3.insert data.....4.create index...5.analyze table table_name compute statistics;重新生成统计数据调整后,整个操作耗时非常少。
第二篇:淘汰落后产能进程缓慢原因浅析淘汰落后产能进程缓慢原因浅析谈到钢材市场的淘汰落后产能,说“谈虎色变”一点也不夸张,从去年以来,各级政府便严控新增产能,其力度之大,时间之久无人不知无人不晓,然而仍有个别地方还在新开工建设钢铁项目,令人担忧。
其实,笔者认为现阶段淘汰落后产能任重而道远,而淘汰的过程也可谓为穿荆度棘,不忍直视。
据了解,现阶段中国钢铁产能超过10亿吨,但市场需求不到8亿吨,由此可以看出钢铁产能过剩的严重程度,实为惊叹。
ORACLE数据库变得非常慢解决方案一例
ORACLE数据库变得非常慢解决方案一例最近在为一个项目做数据库优化,发现ORACLE数据库运行得特别慢,简直让人头大。
今天就来给大家分享一下我是如何一步步解决这个问题的,希望对你们有所帮助。
事情是这样的,那天老板突然过来,一脸焦虑地说:“小王,你看看这个数据库,查询速度怎么这么慢?客户都投诉了!”我二话不说,立刻开始分析原因。
我打开了数据库的监控工具,发现CPU和内存的使用率都很高,看来是数据库的压力确实很大。
然后,我开始查看慢查询日志,发现了很多执行时间很长的SQL语句。
这时,我意识到,问题的根源可能就在这些SQL语句上。
一、分析SQL语句1.对执行时间长的SQL语句进行优化。
我检查了这些SQL语句的写法,发现很多地方可以优化。
比如,有些地方使用了子查询,我尝试将其改为连接查询,以提高查询效率。
2.检查索引。
我发现有些表上没有合适的索引,导致查询速度变慢。
于是,我添加了合适的索引,以提高查询速度。
3.调整SQL语句的顺序。
有些SQL语句的执行顺序不当,导致查询速度变慢。
我调整了这些语句的顺序,使其更加合理。
二、调整数据库参数1.增加缓存。
我发现数据库的缓存设置比较低,导致查询时需要频繁读取磁盘。
我适当增加了缓存大小,以提高查询速度。
2.调整线程数。
我发现数据库的线程数设置较低,无法充分利用CPU资源。
我将线程数调整为合适的值,以提高数据库的处理能力。
3.优化数据库配置。
我对数据库的配置文件进行了调整,比如调整了日志文件的存储路径和大小,以及调整了数据库的备份策略等。
三、检查硬件资源1.检查CPU。
我查看了CPU的使用情况,发现CPU负载较高。
我建议公司采购更强大的CPU,以提高数据库的处理能力。
2.检查内存。
我发现内存的使用率也很高,于是建议公司增加内存容量。
3.检查磁盘。
我检查了磁盘的读写速度,发现磁盘的I/O性能较低。
我建议公司更换更快的磁盘,以提高数据库的读写速度。
四、定期维护1.定期清理数据库。
OracleRAC11gr2性能调优解决查询慢问题
OracleRAC11gr2性能调优解决查询慢问题知也无涯Oracle RAC 11g r2查询太慢---------------------------------------------------Oracle RAC 11g r2查询太慢Problem Description---------------------------------------------------Redhat 5 双机测试1:双实例,ASM磁盘组包含3个磁盘(SAN)。
在其中一个实例中执行:SELECT c.operaccount || ':' || c.PASSWORD || '@' || a.PATH,a.dll, a.description, '1.gif'FROM hcs2000.dllnames a, hcs2000.operdllnames b, hcs2000.operaccount c WHERE a.dllnameid = b.dllnameid AND b.operid = c.operidAND upper(c.operaccount) = USERORDER BY a.dllnameid;第一次查询,25秒。
第二次查询,3秒。
第三次查询,1.6秒。
过10分钟后查询,26秒。
测试2:在其中一台主机上创建基于ASM磁盘组的单个实例,第一次查询,14秒。
第二次查询,3秒。
第三次查询,0.7秒。
第四次查询,3.5秒。
测试3:在其中一台主机上创建基于文件系统的单个实例,第一次查询,5秒。
第二次查询,2.2秒。
第三次查询,2.1秒。
测试4:在PC的VMware虚拟机里面单实例查询,只需0.001秒或0秒。
测试1中的查询太慢了,请问怎么查看问题原因,如何调优?Dear customer,请您执行以下动作:如果可以,请在您提到的4个场景下都生成以下文件,并请添加您的说明后,作为附件更新到SR上:ACTION PLAN-----------------------1. Please generate 10046 trace for your sql:SQL>connect username/passwordSQL>alter session set timed_statistics = true;SQL>alter session set statistics_level=all;SQL>alter session set max_dump_ = unlimited;SQL>alter session set events '10046 trace name context forever, level 12';SQL>SQL>alter session set events '10046 trace name context off';2.Format your 10046 trace file:$tkprof例如生成的文件应该是在您的udump路径下面。
oracle查询慢的原因
oracle查询慢的原因1.查看后台是否有锁:SELECT sq.INST_ID,SQ.SQL_TEXT, /*SQL⽂本*/SE.SID, /*会话的唯⼀标识,通常要对某个会话进⾏分析前,⾸先就需要获得该会话的SID。
*/SE.BLOCKING_SESSION,SQ.OPTIMIZER_COST AS COST_, /* COST 值*/ST_CALL_ET CONTINUE_TIME, /*执⾏时间*/SE.EVENT, /*等待事件*/SE.LOCKWAIT, /*是否等待LOCK(SE,P)*/SE.MACHINE, /*客户端的机器名。
(WORKGROUP\PC-201211082055)*/SQ.SQL_ID, /*SQL_ID*/ERNAME, /*创建该会话的⽤户名*/SE.LOGON_TIME, /*登陆时间*/'ALTER SYSTEM KILL SESSION ''' || SE.SID || ',' || SE.SERIAL# ||''';' KILL --若存在锁情况,会⽤到KILL锁释放~FROM gV$SESSION SE, /*会话信息。
每⼀个连接到ORACLE数据库的会话都能在该视图中对应⼀条记录,根据该视图中的信息可以查询该会话使⽤的⽤户,正在执⾏或者刚刚执⾏的SQL语句*//**/gV$SQLAREA SQ /*跟踪所有SHARED POOL中的共享CURSOR信息,包括执⾏次数,逻辑读,物理读等*/WHERE SE.SQL_HASH_VALUE = SQ.HASH_VALUEAND SE.STATUS = 'ACTIVE'AND SE.SQL_ID = SQ.SQL_IDAND ERNAME = SQ.PARSING_SCHEMA_NAME--过滤条件AND ERNAME = 'FWSB' --⽤户名and se.BLOCKING_SESSION is not null;以下将重点的⼏个列说明⼀下SQL_TEXT——被锁的语句;开发⼈员需要判断,这⾥⾯有没有反馈慢的功能对应的语句。
提高Oracle数据查询速度的方法
提高Oracle数据查询速度的方法摘要:为了提高数据库应用的性能,减少用户的等待时间,有必要对查询速度进行优化。
本文以Oracle数据库为例,首先分析了影响Oracle数据查询速度的各种因素:数据库配置、数据库设计、应用程序的优化,然后基于这些因素提出了优化查询速度的方法,最后通过优化方法举例介绍了实际软件项目中应用的优化方法和策略。
关键词:查询;SQL优化;Oracle;DBA中图分类号:TP311文献标码:A文章编号:1009-3044(2007)05-11208-031 引言大型数据库系统中往往要用到查询统计,但是对于数据量大的系统,用户在进行复杂的查询统计时往往感到速度很慢,不能满足应用要求,这就要求我们在设计数据库系统时进行合理设置,提高查询统计的速度。
本文结合笔者的项目开发经验,从数据库管理到应用开发中的优化来阐述具体的设置方法。
2 影响数据查询速度的因素一个数据库系统是由数据库、用户、软件和硬件资源组成。
数据库(DB)物理地存储用户的数据,数据库中的数据读写,完整性,并发性和安全性由数据库管理系统(DBMS)来控制。
数据库应用开发人员可以使用前端开发工具开发数据库应用程序来完成用户的特定工作任务,从而简化了用户与数据库的交互。
一个数据库应用系统的生命周期可以分成:设计、开发和成品三个阶段。
这三个过程对应数据库的建立,数据库表结构的设计和应用程序的开发。
同时对应不同的阶段又有不同的数据库用户,他们直接或间接地参与到数据库应用系统的开发中,所以这些人的工作方法和经验直接影响到数据库应用系统的性能。
在一个数据库系统中主要分为四类用户:数据库管理员(DBA),数据库设计员,应用程序开发维护人员,终端用户。
这四类用户中除了终端用户通过数据库应用系统间接操作数据库中的数据外,其它人员都直接与数据库进行交互,也是影响数据库应用系统性能的主要因素。
下面我们就从这三个用户的日常工作来分析影响数据库查询效率的因素。
影响ORACLE性能因素
影响ORACLE性能因素任何事情都有它的源头,要解决问题,也得从源头开始,影响ORACLE性能的源头非常多,主要包括如下方面:数据库的硬件配置:CPU、内存、网络条件。
1. CPU:在任何机器中CPU的数据处理能力往往是衡量计算机性能的一个标志,并且ORACLE是一个提供并行能力的数据库系统,在CPU方面的要求就更高了,如果运行队列数目超过了CPU处理的数目,性能就会下降,我们要解决的问题就是要适当增加CPU的数量了,当然我们还可以将需要许多资源的进程KILL 掉;2. 内存:衡量机器性能的另外一个指标就是内存的多少了,在ORACLE中内存和我们在建数据库中的交换区进行数据的交换,读数据时,磁盘I/O必须等待物理I/O操作完成,在出现ORACLE的内存瓶颈时,我们第一个要考虑的是增加内存,由于I/O的响应时间是影响ORACLE性能的主要参数,我将在这方面进行详细的讲解3. 网络条件:NET*SQL负责数据在网络上的来往,大量的SQL会令网络速度变慢。
比如10M的网卡和100的网卡就对NET*SQL有非常明显的影响,还有交换机、集线器等等网络设备的性能对网络的影响很明显,建议在任何网络中不要试图用3个集线器来将网段互联。
OS参数的设置下表给出了OS的参数设置及说明,DBA可以根据实际需要对这些参数进行设置内核参数名说明bufpages对buffer空间不按静态分配,采用动态分配,使bufpages值随nbuf一起对buffer空间进行动态分配。
create_fastlinks对HFS文件系统允许快速符号链接dbc_max_pct加大最大动态buffer空间所占物理内存的百分比,以满足应用系统的读写命中率的需要。
dbc_min_pct设置最小动态buffer空间所占物理内存的百分比desfree提高开始交换操作的最低空闲内存下限,保障系统的稳定性,防止出现不可预见的系统崩溃(Crash)。
fs_async允许进行磁盘异步操作,提高CPU和磁盘的利用率lotsfree提高系统解除换页操作的空闲内存的上限值,保证应用程序有足够的可用内存空间。
影响oracle查询性能的因素都有哪些-
影响oracle查询性能的因素都有哪些?
问题:影响oracle查询性能的因素都有哪些? 回答:
1. 硬件配置:处理器速度,内存大小,磁盘读写速度,网络传输速度等等,这些都影响oracle的整体性能和查询性能
2. 是否建立了索引,索引是否合理
3. 表碎片和索引碎片,生产库由于长时间运营,碎片可能导致查询使用错误的执行计划,导致查询速度变慢
4. 表或者索引的initial 参数配置不同,导致数据扩展区大小不一,也可能导致查询速度降低。
5. SQL执行效率低下,导致查询速度很慢
6. 数据库负载过大
1。
数据库查询性能差的原因分析与解决方案
数据库查询性能差的原因分析与解决方案一、引言数据库查询性能是决定系统整体性能的重要因素之一。
当数据库查询性能差时,会导致系统响应时间延长、效率低下,影响用户体验和系统的可用性。
因此,深入分析查询性能差的原因,并提出有效的解决方案,对于提升系统性能具有重要意义。
二、数据库查询性能差的原因分析1. 数据库设计问题:良好的数据库设计能够提高查询性能。
如果数据库的表结构设计不合理,如表之间存在冗余数据、缺乏索引、表字段不合理等,都会导致查询性能下降。
2. 查询语句问题:查询语句的编写有时会导致性能问题。
当查询语句中存在大量的连接操作、子查询、不合理的顺序等,都会增加系统查询负担,导致性能下降。
3. 数据量过大:当数据库中数据量超过一定程度时,查询性能就会明显下降。
数据量过大会导致磁盘I/O负载加重,从而降低系统的响应速度。
4. 硬件资源问题:硬件资源不足也会影响数据库查询性能。
例如,内存容量不足、磁盘I/O速度慢,都会限制数据库的查询能力。
5. 数据库参数配置问题:数据库的参数配置对于查询性能有着重要的影响。
如果数据库的参数配置不合理,比如缓冲区设置过小、线程数配置不当等,都会导致查询性能下降。
三、解决方案1. 优化数据库设计:对于已经存在的数据库,可以通过对表进行重构、去除冗余数据、合理设计索引等方式来优化数据库结构,从而提高查询性能。
2. 优化查询语句:仔细审查查询语句,避免使用不必要的连接操作和子查询。
编写高效的查询语句,可以使用合适的索引、合理的顺序等来加快查询速度。
3. 数据分区和分页:对于数据量过大的表,可以考虑进行数据分区,将数据分散存储,从而减少单个查询操作的数据量。
对于查询结果过多的情况,可以使用分页查询,限制一次查询的结果条数,减少数据的传输和加载。
4. 提升硬件资源:根据实际情况,考虑提升硬件资源。
可以增加内存容量,加快磁盘I/O速度,提高服务器的计算性能,从而提升数据库查询性能。
提高Oracle的查询统计速度方法简介
以Oracle7.33数据库系统为例,我们在开发大型Oracle数据库系统时结合项目的特点,本着安全、高效的原则对数据库进行了一些物理设计,从而大大提高了数据库的查询统计速度。
总结为如下几点:1)扩大数据表空间到500MB,用于存放本系统的数据;2)段盘区的初始大小为10KB,增长大小为10KB,增长幅度为1;3)用户临时空间增大40MB;4)系统临时表空间和回滚段表空间增大40MB,并且新建4个回滚段;5)需要经常联结查询,而且数据量又大的库存表、名录表、收发料表放在一簇内;6)提供定时备份,备份文件放在另外的机器上。
设置数据表空间的SQL语句如下:CREATE TABLESPACE WXGL_DATA1 DATAFILE 'WXGL_DATA1.ORA' SIZE 500M ONLINE;增加系统临时表空间和回滚段表空间的SQL语句如下:ALTER TABLESPACE TEMPORARY_DATA ADD DATAFILE 'TMP2ORCL.ORA' SIZE 40M;ALTER TABLESPACE ROLLBACK_DATA ADD DATAFILE 'RBS2ORCL.ORA' SIZE 40M;将数据空间设置在指定的数据文件的SQL语句如下:CREATE USER ZBGL IDENTIFIED BY ZBGL;GRANT DBA TO ZBGL;ALTER USER ZBGL DEFAULT TABLESPACE WXGL_DATA1 TEMPORARY TABLESPACE TEMPORARY_DATA;设置五个回滚段的SQL语句如下:SELECT SEGMENT_NAME FROM DBA_ROLLBACK_SEGS WHERE INITIAL_EXTENT UPPPER(OWNER) = 'PUBLIC';SELECT UPPER(STA TUS) FROM DBA_ROLLBACK_SEGS WHERE UPPER(SEGMENT_NAME) = ''ALTER ROLLBACK SEGMENT RB1 OFFLINE;ALTER ROLLBACK SEGMENT RB2 OFFLINE;ALTER ROLLBACK SEGMENT RB3 OFFLINE;ALTER ROLLBACK SEGMENT RB4 OFFLINE;ALTER ROLLBACK SEGMENT RB5 OFFLINE;DROP ROLLBACK SEGMENT RB1;DROP ROLLBACK SEGMENT RB2;DROP ROLLBACK SEGMENT RB3;DROP ROLLBACK SEGMENT RB4;DROP ROLLBACK SEGMENT RB5;CREATE PUBLIC ROLLBACK SEGMENT RB1 TABLESPACE ROLLBACK_DATA STORAGE (INITIAL 512000 NEXT 512000 MAXEXTENTS 121);CREATE PUBLIC ROLLBACK SEGMENT RB2 TABLESPACE ROLLBACK_DATA STORAGE (INITIAL 512000 NEXT 512000 MAXEXTENTS 121);CREATE PUBLIC ROLLBACK SEGMENT RB3 TABLESPACE ROLLBACK_DATASTORAGE (INITIAL 512000 NEXT 512000 MAXEXTENTS 121);CREATE PUBLIC ROLLBACK SEGMENT RB4 TABLESPACE ROLLBACK_DATA STORAGE (INITIAL 512000 NEXT 512000 MAXEXTENTS 121);CREATE PUBLIC ROLLBACK SEGMENT RB5 TABLESPACE ROLLBACK_DATA STORAGE (INITIAL 512000 NEXT 512000 MAXEXTENTS 121);ALTER ROLLBACK SEGMENT RB1 ONLINE;ALTER ROLLBACK SEGMENT RB2 ONLINE;ALTER ROLLBACK SEGMENT RB3 ONLINE;ALTER ROLLBACK SEGMENT RB4 ONLINE;ALTER ROLLBACK SEGMENT RB5 ONLINE;COMMIT;将数据量大的库存表等放在一簇内的SQL语句如下:KCB='CREATE TABLE QC_KCB( '+' CKNM NUMBER(8) ,'+' QCNM NUMBER(10) ,'+' CKKC NUMBER(12,2),'+' SNCKKC NUMBER(12,2),'+' LDJ NUMBER(12,2),'+' BZ V ARCHAR(100),'+' PRIMARY KEY(CKNM,QCNM))'+' TABLESPACE WXGL_DA TA1 ' ; (大数据量的库存表等放在WXGL_DATA1) QCFL = 'CREATE TABLE QC_QCFL '+ '(FLBH NUMBER(2) PRIMARY KEY,'+ ' FLMC VARCHAR(20) '+ ' ) '+' TABLESPACE WXGL_DA TA2 ' ;(其他表放在WXGL_DA TA2)系统的基础数据库存表、名录表大约有数据80M;一个单位一般每年收发300次,收发料单大约有数据50M;系统冗余数据100M,系统辅助数据10M;因此,系统总共需要空间大约是240M,现在系统开辟数据空间500M,完全满足存储要求。
- 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。
Oracle查询慢的原因总结查询速度慢的原因很多,常见如下几种:1、没有索引或者没有用到索引(这是查询慢最常见的问题,是程序设计的缺陷)2、I/O吞吐量小,形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足5、网络速度慢6、查询出的数据量过大(可以采用多次查询,其他的方法降低数据量)7、锁或者死锁(这也是查询慢最常见的问题,是程序设计的缺陷)8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列10、查询语句不好,没有优化可以通过如下方法来优化查询:1、把数据、日志、索引放到不同的I/O设备上,增加读取速度,以前可以将Tempdb应放在RAID0上,SQL2000不在支持。
数据量(尺寸)越大,提高I/O越重要。
2、纵向、横向分割表,减少表的尺寸(sp_spaceuse)3、升级硬件4、根据查询条件,建立索引,优化索引、优化访问方式,限制结果集的数据量。
注意填充因子要适当(最好是使用默认值0)。
索引应该尽量小,使用字节数小的列建索引好(参照索引的创建),不要对有限的几个值的字段建单一索引如性别字段5、提高网速;6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。
配臵虚拟内存:虚拟内存大小应基于计算机上并发运行的服务进行配臵。
运行 Microsoft SQL Server? 2000 时,可考虑将虚拟内存大小设臵为计算机中安装的物理内存的 1.5 倍。
如果另外安装了全文检索功能,并打算运行Microsoft 搜索服务以便执行全文索引和查询,可考虑:将虚拟内存大小配臵为至少是计算机中安装的物理内存的 3 倍。
将 SQL Server max server memory 服务器配臵选项配臵为物理内存的 1.5 倍(虚拟内存大小设臵的一半)。
7、增加服务器 CPU个数;但是必须明白并行处理串行处理更需要资源例如内存。
使用并行还是串行程是MsSQL自动评估选择的。
单个任务分解成多个任务,就可以在处理器上运行。
例如耽搁查询的排序、连接、扫描和GROUP BY字句同时执行,SQL SERVER根据系统的负载情况决定最优的并行等级,复杂的需要消耗大量的CPU的查询最适合并行处理。
但是更新操作Update,Insert, Delete还不能并行处理。
8、如果是使用like进行查询的话,简单的使用index是不行的,但是全文索引,耗空间。
like 'a%' 使用索引 like '%a' 不使用索引用 like '%a%' 查询时,查询耗时和字段值总长度成正比,所以不能用CHAR 类型,而是VARCHAR.对于字段的值很长的建全文索引。
9、DB Server 和APPLication Server 分离;OLTP和OLAP分离10、分布式分区视图可用于实现数据库服务器联合体。
联合体是一组分开管理的服务器,但它们相互协作分担系统的处理负荷。
这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器,以支持大型的多层 Web 站点的处理需要。
有关更多信息,参见设计联合数据库服务器。
(参照SQL帮助文件'分区视图')a、在实现分区视图之前,必须先水平分区表b、在创建成员表后,在每个成员服务器上定义一个分布式分区视图,并且每个视图具有相同的名称。
这样,引用分布式分区视图名的查询可以在任何一个成员服务器上运行。
系统操作如同每个成员服务器上都有一个原始表的复本一样,但其实每个服务器上只有一个成员表和一个分布式分区视图。
数据的位臵对应用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设臵自动收缩日志。
对于大的数据库不要设臵数据库自动增长,它会降低服务器的性能。
在T-sql的写法上有很大的讲究,下面列出常见的要点:首先, DBMS处理查询计划的过程是这样的:1、查询语句的词法、语法检查2、将语句提交给DBMS的查询优化器3、优化器做代数优化和存取路径的优化4、由预编译模块生成查询规划5、然后在合适的时间提交给系统处理执行6、最后将执行结果返回给用户其次,看一下SQL SERVER的数据存放的结构:一个页面的大小为8K (8060)字节,8个页面为一个盘区,按照B树存放。
12、Commit和rollback的区别 Rollback:回滚所有的事物。
Commit:提交当前的事物。
没有必要在动态SQL里写事物,如果要写请写在外面如: begin tran exec(@s) commit trans 或者将动态SQL 写成函数或者存储过程。
13、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据,浪费了服务器的I/O资源,加重了网络的负担降低性能。
如果表很大,在表扫描的期间将表锁住,禁止其他的联接访问表,后果严重。
14、SQL的注释申明对执行没有任何影响15、尽可能不使用光标,它占用大量的资源。
如果需要row-by-row地执行,尽量采用非光标技术,如:在客户端循环,用临时表,Table变量,用子查询,用Case语句等等。
游标可以按照它所支持的提取选项进行分类:只进必须按照从第一行到最后一行的顺序提取行。
FETCH NEXT 是唯一允许的提取操作,也是默认方式。
可滚动性可以在游标中任何地方随机提取任意行。
游标的技术在SQL2000下变得功能很强大,他的目的是支持循环。
有四个并发选项 READ_ONLY:不允许通过游标定位更新(Update),且在组成结果集的行中没有锁。
OPTIMISTIC WITH valueS:乐观并发控制是事务控制理论的一个标准部分。
乐观并发控制用于这样的情形,即在打开游标及更新行的间隔中,只有很小的机会让第二个用户更新某一行。
当某个游标以此选项打开时,没有锁控制其中的行,这将有助于最大化其处理能力。
如果用户试图修改某一行,则此行的当前值会与最后一次提取此行时获取的值进行比较。
如果任何值发生改变,则服务器就会知道其他人已更新了此行,并会返回一个错误。
如果值是一样的,服务器就执行修改。
选择这个并发选项 OPTIMISTIC WITH ROW VERSIONING:此乐观并发控制选项基于行版本控制。
使用行版本控制,其中的表必须具有某种版本标识符,服务器可用它来确定该行在读入游标后是否有所更改。
在 SQL Server 中,这个性能由 timestamp 数据类型提供,它是一个二进制数字,表示数据库中更改的相对顺序。
每个数据库都有一个全局当前时间戳值:@@DBTS.每次以任何方式更改带有 timestamp 列的行时,SQL Server 先在时间戳列中存储当前的 @@DBTS 值,然后增加 @@DBTS 的值。
如果某个表具有 timestamp 列,则时间戳会被记到行级。
服务器就可以比较某行的当前时间戳值和上次提取时所存储的时间戳值,从而确定该行是否已更新。
服务器不必比较所有列的值,只需比较 timestamp 列即可。
如果应用程序对没有 timestamp 列的表要求基于行版本控制的乐观并发,则游标默认为基于数值的乐观并发控制。
SCROLL LOCKS 这个选项实现悲观并发控制。
在悲观并发控制中,在把数据库的行读入游标结果集时,应用程序将试图锁定数据库行。
在使用服务器游标时,将行读入游标时会在其上放臵一个更新锁。
如果在事务内打开游标,则该事务更新锁将一直保持到事务被提交或回滚;当提取下一行时,将除去游标锁。
如果在事务外打开游标,则提取下一行时,锁就被丢弃。
因此,每当用户需要完全的悲观并发控制时,游标都应在事务内打开。
更新锁将阻止任何其它任务获取更新锁或排它锁,从而阻止其它任务更新该行。
然而,更新锁并不阻止共享锁,所以它不会阻止其它任务读取行,除非第二个任务也在要求带更新锁的读取。
滚动锁根据在游标定义的 Select 语句中指定的锁提示,这些游标并发选项可以生成滚动锁。
滚动锁在提取时在每行上获取,并保持到下次提取或者游标关闭,以先发生者为准。
下次提取时,服务器为新提取中的行获取滚动锁,并释放上次提取中行的滚动锁。
滚动锁独立于事务锁,并可以保持到一个提交或回滚操作之后。
如果提交时关闭游标的选项为关,则 COMMIT 语句并不关闭任何打开的游标,而且滚动锁被保留到提交之后,以维护对所提取数据的隔离。
所获取滚动锁的类型取决于游标并发选项和游标 Select 语句中的锁提示。
锁提示只读乐观数值乐观行版本控制锁定无提示未锁定未锁定未锁定更新 NOLOCK 未锁定未锁定未锁定未锁定HOLDLOCK 共享共享共享更新 UPDLOCK 错误更新更新更新 TABLOCKX 错误未锁定未锁定更新其它未锁定未锁定未锁定更新 *指定 NOLOCK 提示将使指定了该提示的表在游标内是只读的。
16、用Profiler来跟踪查询,得到查询所需的时间,找出SQL的问题所在;用索引优化器优化索引17、注意UNion和UNion all 的区别。
UNION all好18、注意使用DISTINCT,在没有必要时不要用,它同UNION一样会使查询变慢。
重复的记录在查询里是没有问题的19、查询时不要返回不需要的行、列20、用sp_configure 'query governor cost limit'或者SET QUERY_GOVERNOR_COST_LIMIT来限制查询消耗的资源。
当评估查询消耗的资源超出限制时,服务器自动取消查询,在查询之前就扼杀掉。
SET LOCKTIME设臵锁的时间21、用select top 100 / 10 Percent 来限制用户返回的行数或者SET ROWCOUNT来限制操作的行22、在SQL2000以前,一般不要用如下的字句: "IS NULL", "<>", "!=", "!>", "!<", "NOT","NOT EXISTS", "NOT IN", "NOT LIKE", and "LIKE '%500'",因为他们不走索引全是表扫描。
也不要在Where字句中的列名加函数,如Convert,substring等,如果必须用函数的时候,创建计算列再创建索引来替代。
还可以变通写法:Where SUBSTRING(firstname,1,1) = 'm'改为Where firstname like 'm%'(索引扫描),一定要将函数和列名分开。